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Publico-alvo 


Este livro é para pessoas que já conheçam um pouco sobre a estrutura de 
um projeto web utilizando a linguagem JAVA. O mínimo de JSF vai ajudar 
para que você consiga acompanhar a construção da aplicação WEB de uma 
maneira mais fluida, mas fique tranquilo, pois tudo do JSF será explicado para 
você. Quase todo capítulo vai cobrir detalhes que vão além do uso normal e 
vai deixá-lo mais crítico em relação ao uso da tecnologia. 

Considere também que o livro é sobre o JAVA EE como plataforma, então 
existem várias outras especificações que serão cobertas e que lhe deixará mais 
embasado para tomar suas futuras decisões em relação à plataforma. 
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CAPITULO 1 


Introdução 


Por muito tempo, a especificação Java EE (Java Enterprise Edition) ficou co- 
nhecida como sendo algo extremamente complexo de ser entendido. Caso 
você tenha trabalhado com as primeiras versões ou conhece alguém que tra- 
balhou, deve se lembrar da complicação que era configurar cada uma das tec- 
nologias, e também o quão trabalhoso era fazê-las funcionarem em conjunto. 

Pois bem, essas lembranças ficaram em um passado distante. O surgi- 
mento de outros frameworks no mercado, notoriamente o Spring, fizeram 
com que as empresas responsáveis por evoluir a especificação se movimen- 
tassem. 

Desde a versão 5, o Java EE vem evoluindo a passos largos tanto pelo lado 
da configuração das tecnologias envolvidas quanto pelo prisma da integração 
entre elas. Com a entrada do CDI (Context Dependency Injection) na versão 
6, as integrações pararam de girar em torno dos EJBs (Enterprise JavaBean) 
e tudo ficou mais simples de ser trabalhado. A versão 7, que é a atual, deixou 
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tudo ainda mais fácil, e trouxe novas melhorias no CDI, além de também 
deixar muito mais simples a integração com sistemas de mensageria. E esses 
são apenas dois dos exemplos. 

Com toda essa desburocratização, as tecnologias envolvidas na especifica- 
ção e, por consequência, os servidores que as implementam - como o Wildfly 
(antigo Jboss) -, alçaram novos voos. Hoje, aquela história que Java EE era só 
para empresas gigantes não é mais válida. Qualquer tipo de aplicação, dentro 
de qualquer empresa, pode tirar proveito da última versão da especificação. 

A partir de agora, tudo o que eu comentar é relativo à versão 7 do Java 
EE. Se em algum momento eu precisar referenciar outra versão, você será 
devidamente avisado. 


1.1 POR QUE O JAVA EE? 


Quase todas as aplicações possuem certas funcionalidades que exigem um 
certo conjunto de tecnologias, que vivem se repetindo entre elas. Alguns 
exemplos mais comuns são: 


e Mandar e-mail; 
e Gravar dados no banco de dados; 


e Fazer a segurança da aplicação; 


Expor a aplicação na web. 


Podemos também pensar em tecnologias necessárias para outras funcio- 
nalidades, vistas mais comumente em aplicações maiores: 


e Integração via mensageria; 
* Integração via REST; 
e WebSockets para alertar usuários sobre algo; 


e Realização de tarefas assíncronas. 
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Você provavelmente já caiu (ou vai cair) em uma aplicação que demande 
a integração de muitas das coisas que acabamos de listar. E é nesse tipo de 
cenário que possuir um servidor que já traz todas essas implementações de- 
cididas pode ajudar bastante. 


Dê uma olhada no conjunto de especificações que compõem o Java EE 7. 








JSP 2.2 Java API for JSON Java API for 
JSF 2.2, JSF 2.2 JAX-RS 2.0 (JSR 353) WebSocket 
EL3.0 (JSR 356) 
CDI Portable 
Extensions 
Serviet3.1 
5 Concurrency Utilities 
paren rca! Interceptors 1.1 L1 USR 236) 
Managed Beans 1.0 EJB3.2 
Batch Applications 
JCA 1.7 JPA 2.1 STA 1.2 JMS 2.0 USR 352) 





Fig. 1.1: Especificações do Java EE 


Perceba que são muitas coisas, e tudo isso é entregue pronto para você. 
Não vamos ser mentirosos e dizer que tudo vai funcionar lindamente sem 
nenhuma gota de suor, mas, hoje em dia, o trabalho para configurar e tirar 
proveito de cada uma delas está muito menor. Você ficará surpreso com a 
facilidade com que quase todas nossas funcionalidades serão implementadas! 

Baseado nessa evolução, escolher um servidor Java EE para sua próxima 
aplicação é uma consideração que se faz necessária, mesmo sabendo que a 
competição continua acirrada, já que os competidores, como o Spring, não 
pararam de evoluir também. 

Um outro ponto altamente relevante é o quanto de ajuda você pode obter 
através da internet. Nesse ponto, os projetos relacionados ao Java EE, como o 
JSF (JavaServer Faces), também se beneficiam bastante. 
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1.2 SPRING X JAVA EE 


Essa é uma outra discussão que quase sempre acaba aparecendo. Ha muito 
tempo, nas primeiras versões do Java EE, não tinha comparação, o ecossis- 
tema do Spring era realmente uma alternativa melhor. Nem era muito sim- 
ples de configurar como é hoje, mas, mesmo assim, era muito mais fácil do 
que qualquer coisa necessária para o Java EF. 

Nos dias de hoje, as duas frentes estão muito fortes. Ambas possuem im- 
plementações que se destacam frente à concorrente e, com isso, a decisão de 
seguir por um lado ou pelo outro deve ser tomada com base no que o seu 
projeto precisa. 

Minha função com este livro é fornecer uma visão pragmática sobre o Java 
EE. Não esconderei nada e você mesmo será capaz de avaliar qual conjunto 
de tecnologias é melhor para a sua empresa ou para o próximo projeto. Não 
é à toa que eu também já escrevi o livro Spring MVC: Domine o principal 
framework web Java, pela Casa do Código. Melhor do que nos apaixonarmos 
pela tecnologia é sabermos tirar proveito delas em função do cenário que se 
apresenta. 


1.3 COMECE A AVENTURA 


Durante o livro, vamos construir uma aplicação muito parecida com o próprio 
site da Casa do Código. Desenvolveremos funcionalidades que nos levarão ao 
uso de diversas das especificações do Java EE, como: 


Bean validation para validarmos os nossos dados; 


e Processamento assincrono via JMS; 


JSF 2.2 e algumas das suas novidades, como a integração com o HTML 
5 


WebSockets para notificarmos usuários de promoções relâmpagos; 


e CDI para isolarmos a criação de componentes e ajudarmos na compo- 
sição de regras de negócios; 
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e JAX-RS para possibilitarmos integrações via REST; 
e JPA para acesso a banco de dados, além de sua API de cache; 


* Um pouco sobre EJBs e um caso de uso bem interessante; 


JAAS para adicionarmos autenticação e autorização; 


Java Mail para mandarmos e-mails de finalização de compra. 
* JTA para controlarmos as transações. 


* Um pouco sobre a Concurrency Utilities API para termos Threads ge- 
renciadas pelo container. 


e O suficiente sobre a JNDI para conseguirmos buscar os objetos neces- 
sários dentro do servidor. 


1.4 PÚBLICO-ALVO 


O público seria as pessoas que já conhecem um pouco sobre a estrutura de 
um projeto baseado no Design Pattern MVC, através do JSF O mínimo de 
JSF ajudará você a conseguir acompanhar a construção da aplicação WEB. 

Mas fique tranquilo, pois tudo além do básico do JSF será explicado para 
você. Quase todo capítulo vai cobrir detalhes que vão além do uso normal e 
vai deixá-lo mais crítico em relação ao uso da tecnologia. 


1.5 CURIOSIDADE: POR QUE JSF COMO FRAMEWORK? 


A nossa aplicação web vai ser baseada na Casa do Código e, talvez, alguns de 
vocês pensem: por que será usado o JSF? Ele não é mais comumente usado 
em sistemas web que, na verdade, funcionam quase como sistemas desktop? 
Sim, isso é verdade. Em contrapartida, o JSF 2.2 evoluiu em relação ao con- 
trole do HTML gerado, dando-nos a possibilidade de construir páginas mais 
condizentes com as necessidades atuais. 

Além disso, durante o livro, será usada uma abordagem que deixará o JSF 
mais próximo dos frameworks Action Based com que somos acostumados, 
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mesmo ele sendo um framework muito conhecido por ser baseado em com- 
ponentes, o famoso Component Basead. 

Complementando, ele é uma das especificações oficiais do Java EE e, 
como no livro vamos discutir a especificação, nada mais justo que usarmos a 
tecnologia indicada por ela. 





NÃO FIQUE PERDIDO! 


Todo o código-fonte do livro está disponível no GitHub, basta acessar 
o endereço https://github.com/asouza/casadocodigojavaee. 

Fique à vontade para navegar pelos arquivos do projeto. Os commits 
foram divididos de acordo com os capítulos do livro, justamente para que 
você possa acessar o código compatível com o capítulo que esteja lendo. 

Além disso, foi criado um grupo de discussão, no qual você pode pos- 
tar todas as suas dúvidas referentes à leitura. Para acessá-lo, basta seguir 
este link: https://groups.google.com/forum/#!forum/livro-javaee. 











1.6 VAMOS LÁ? 


Fique junto comigo e leia cada capítulo com calma; eu sempre lhe direi se é 
hora de dar uma pausa ou de já pular para o próximo. Espero que você tenha 
uma grande jornada! 


CAPITULO 2 


Começando o projeto 


2.1 CONFIGURAÇÃO E CRIAÇÃO DO PROJETO 


O objetivo do livro é construir uma aplicação semelhante à da própria Casa 
do Código. Por ser um site de e-commerce, a aplicação nos fornece a chance 
de implementar diversas funcionalidades. Além disso, é um domínio que não 
vai nos causar muitas dúvidas. 


No final do livro, a nossa aplicação terá a seguinte cara: 
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Fig. 2.1: Site da Casa do Cédigo 


A primeira coisa que precisamos fazer é justamente criar e configurar o 
mínimo necessário para ter nossa aplicação, rodando corretamente com o 
JSF. Como vamos usar o Maven para gerenciar as nossas dependências, so- 
mos obrigados a criar o projeto seguindo uma estrutura determinada por essa 
ferramenta. 


O layout das pastas, como de costume, vai seguir o seguinte formato: 
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=“ scadocodigo 
Workspace c/main/java 
> C src/main/resources 
( src/test/java 
( src/test/resources 
+ mi, Maven Dependencies 
P ms, JRE System Library lavaSE-1 
> (> imagens-textos-livro 
Y src 
Y main 
¥ (2webapp 
= EE 
(test 
> (> target 





“~ 


Fig. 2.2: Estrutura das pastas 


Provavelmente, você já deve ter feito esta atividade algumas vezes, então, 
para mudar um pouco a sua rotina, vou utilizar um modo um pouco diferente 
de criar o projeto. Usaremos um projeto da Red Hat, chamado Jboss Forge, 
que pode ser baixado em http://forge.jboss.org/download. 

O Jboss Forge fornece vários comandos prontos para a criação de projetos. 
Após baixado, extraia o arquivo em uma pasta de sua preferência. Acesse o 
terminal do seu computador e digite o seguinte comando: 


$caminhoParaSuaInstalacao/bin/forge 


Isso abrirá uma aplicação no próprio console. 





| a 2 
| DD esa ye a 
Vo eo bd tah he Re 
fc)" Veep Ace E | 
l 
JBoss Forge, version [ 2.13.0.Final ] - JBoss, by Red Hat, Inc. [ http://forge.jboss.org ] 


[javals É 


Fig. 2.3: Console do Forge 


21. Configuração e criação do projeto Casa do Código 





Agora, basta que digitemos o comando responsável pela criação do pro- 
jeto. 


project-new --named casadocodigo 


Pronto! Isso é suficiente para você criar o seu projeto baseado no Ma- 
ven. A estrutura de pastas já está pronta, só precisamos realizar as devidas 
configurações. 


Dependências necessárias 


Precisamos adicionar todas as dependências necessárias para que seja 
possível começarmos a trabalhar no projeto. Essa já é uma das partes bem 
interessantes de trabalhar em um projeto fortemente baseado nas especifica- 
ções do Java EE. 

Como quase todas as dependências importantes já vêm prontas dentro do 
servidor que vamos usar, nós quase não precisamos alterar o pom.xml. Para 
não ficarmos perdendo tempo realizando essas configurações, vamos mais 
uma vez utilizar o console do Forge. 

Entre na pasta criada para o seu projeto e rode o Forge mais uma vez. De 
dentro do console, escreva o seguinte comando: 


faces-setup --facesVersion 2.2 


Depois da execução, deve aparecer uma mensagem de sucesso, parecida 


com essa: 


**SUCCESS** JavaServer Faces has been installed. 


Sem esforço nenhum, acabamos de criar tudo o que é necessário para ter 
nosso projeto com JSF rodando. 

Como não queremos usar configurações das quais não temos conheci- 
mento, vamos passear pelas alterações realizadas pelo comando. Um primeiro 
arquivo que podemos olhar éo pom.xml, responsável por gerenciar nossas 
dependências. 


<dependencyManagement> 
<dependencies> 
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<dependency> 
<groupId>org. jboss.spec</groupId> 
<artifactId>jboss-javaee-6.0</artifactId> 
<version>3.0.2.Final</version> 
<type>pom</type> 
<scope>import</scope> 
</dependency> 
<dependency> 
<groupId>javax.faces</groupId> 
<artifactId>javax.faces-api</artifactId> 
<version>2.2</version> 
<scope>provided</scope> 
</dependency> 
</dependencies> 
</dependencyManagement> 
<dependencies> 
<dependency> 
<groupId>javax.faces</groupId> 
<artifactId>javax.faces-api</artifactId> 
<scope>provided</scope> 
</dependency> 
</dependencies> 


Aqui, as dependências foram geradas com a tag 
dependencyManagement. Esta geralmente é usada quando estamos 
nos preocupando em criar projetos que podem precisar das mesmas con- 
figurações de um certo projeto “pai” Não é o nosso caso, mas também 
não interfere em nada no nosso trabalho, inclusive você pode até apagar o 
conteúdo dela. A única coisa em que temos de prestar atenção é que, quando 
for necessário adicionar novas libs manualmente, vamos sempre usar a 
tag <dependency> dentro da <dependencies>. Só o que está dentro de 
<dependencies> é realmente importado para o projeto. 

Ainda em relação às dependências, perceba que ele adicionou a especi- 
ficação do JSF com o escopo provided. Como vamos rodar nosso código 
dentro de um servidor de aplicação, no caso o Wildfly, todas essas bibliotecas 
já estarão disponíveis. Só a deixamos no pom.xml, porque vamos precisar 
usar as classes dentro do nosso projeto. Também, para que a IDE (Integrated 
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Development Environment) compile, ela precisará ter acesso aos jars, pelo 
menos em tempo de compilação. 


Além desse arquivo, também foi gerado um outro, chamado 





faces-config.xml, criado na pasta WEB-INF. Mais para a frente, 
vamos usá-lo para realizar configurações relativas ao JSF; por enquanto, 
segure a ansiedade. 


Habilitando o CDI 


Como já comentamos, o CDI é a especificação que faz a cola entre as di- 
versas especificações. Como não poderia ser diferente, vamos usá-la intensa- 
mente durante a construção de nosso projeto. Por conta disso, é interessante 
já deixar esse passo configurado. 


De novo, vamos usar o Forge para gerar as configurações necessárias. 
Dentro do console, execute o seguinte comando: 


cdi-setup --cdiVersion 1.1 


Mais uma vez, o pom.xml foi alterado, agora para adicionar as depen- 
dências necessárias para o CDI, e mais uma vez elas foram configuradas como 
provided, já que estarão disponíveis dentro do nosso servidor de aplicações. 


<dependencyManagement> 


<dependency> 
<groupId>org.jboss.spec</groupld> 
<artifactId>jboss-javaee-6.0</artifactId> 
<version>3.0.2.Final</version> 
<type>pom</type> 
<scope>import</scope> 

</dependency> 

<dependency> 
<groupld>javax.enterprise</groupId> 
<artifactId>cdi-api</artifactId> 
<version>1.1</version> 
<scope>provided</scope> 

</dependency> 
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</dependencyManagement> 


<dependencies> 
<dependency> 
<groupld>javax.enterprise</groupId> 
<artifactId>cdi-api</artifactId> 
<scope>provided</scope> 
</dependency> 
</dependencies> 





Além disso, dentro da pasta WEB-INF, foi criado mais um arquivo, dessa 
vez o beans.xml. 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 

<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" 

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
bean-discovery-mode="all" version="1.1" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
http://xmlns. jcp.org/xml/ns/javaee/beans_1_1.xsd" /> 


Este é o arquivo necessário para habilitar o funcionamento do CDI no 
seu projeto. Preste atenção no atributo bean-discovery-mode, ele está 
configurado com o valor all. Isso quer dizer que toda classe criada den- 
tro do nosso projeto sera carregada e controlada pela implementação do CDI 
que será usada. Você será lembrado disso quando começarmos realmente a 
produzir o código. 

Perceba que o uso do Forge nos poupou um pouco de trabalho de ter de 
ficar criando os arquivos e colocando-os nos seus devidos lugares. É uma 
ferramenta muito boa, e você pode automatizar diversos setups dos seus pro- 
jetos. 


Importando o projeto para a IDE 


Como estamos usando o Wildfly e escrevendo um projeto baseado no 
Java EE, vou sugerir que você tenha mais uma experiência diferente e use o 
JBoss Developer Studio. Ele é uma IDE baseada no Eclipse, e customizada 
pela Red Hat para atender quem deseja trabalhar mais intensamente com o 
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Casa do Código 





Java EE. Caso opte por ela, o download pode ser realizado em http://www. 
jboss.org/products/devstudio/download/. 


Diferente do Eclipse tradicional, o Developer Studio traz um wizard de 
instalação. Basta seguir os passos sugeridos por ele. 


Veja algumas telas que são importantes: 








BA Red Hat JBoss Developer Studio 8.1.0.GA | 
RED HAT JBOSS 
none 

Introduction 
Step 1 of 9 


(@ Please read the following information: 





‘This installer will guide you through the installation of Red Hat JBoss Developer Studio 8.1.0.GA. 


(Click the "Next" button to proceeded to the next screen. If you want to change something on a previous screen, click 
ithe "Previous" button. 


[You may stop this installation at any time by clicking the "Quit" button- 





JBoss by Red Hat 








> Next | |E qui 





Fig. 2.4: Primeiro passo da instalação 
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Select Target Folder 
Step 3 of 9 


[E Select the installation path: 


Er 





JBoss by Red Hat 





| < Previous j > Next Q Quit 


Fig. 2.5: Escolha sua pasta de instalação 
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soo Red Hat JBoss Developer Studio 8.1,0.GA 








RED HAT JBOSS 
anja 
Select Platforms and Servers 


Step 5 of 9 


JBoss Developer Studio includes Red Hat JBoss Enterprise Application Platform. Install it now? 

LO Yes, and have it ready for use in JBoss Developer Studio 

(e) Na 
Add locations you want to be scanned to discover platforms and servers you have: 

Scan every start Location > wa 





Remove 





JBoss by Red Hat 


| <@ Previous | | O quit | 
Fig. 2.6: Outros plugins da Red Hat não são necessários 
Vamos importar o projeto como um Maven Project; assim, para cada 


nova dependência necessária, basta alterarmos o pom. xml, e a própria IDE 
se encarregará de atualizar o nosso classpath. 


New > 
Show In X#W > 
Copy E: 
Copy Qualified Name 
[E Paste #V 
X Delete E 

Èa Export... 
«? Refresh F5 





Fig. 2.7: Selecione a opção import 
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Select 
M 
Import Existing Maven Projects [253] 
Select an import source: 
| maven Qi 
| Y Maven 





EI Check out Maven Projects from SCM 


Mo Existing Maven Projects 
5, Install or deploy an artifact to a Maven repository 
EJ Materialize Maven Projects from SCM 















@ o <Back | ies ( cancel Finish | 


Fig. 2.8: Escolha o Maven Project 
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eneo Import Maven Projects 
Maven Projects 





Select Maven projects 


Root Directory: | /Users/alberto/ambiente/desenvolvimento/jboss-developer-tools/casadoc + | | Browse... 





Projects: 
M {pom.xml br.com.casadocodigo:casadocodigo:1.0.0-SNAPSHOT-war | Select All | 
| Deselect All | 
Select Tree 


Deselect Tree 


| Refresh | 
|_| Add project(s) to working set 
casadocodigo 
b Advanced 
D [ <Back | Next > | Cancel [= Finish) 


Fig. 2.9: Aponte para o endereço onde seu projeto foi criado 


Pronto, agora temos nosso projeto importado. O último passo é adicioná- 
lo a um servidor, para que possamos realizar nossos testes e ver como a apli- 
cação vai andando. 

Para isso, vamos seguir o caminho padrão de criação de servidores dentro 


do Eclipse. Apenas para nos localizarmos, os próximos passos deverão ser 
realizados na aba Servers do seu Eclipse. 
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\® Problems 4 Servers 53 ‘=> Forge Console © Openshift Explorer 


No servers are available. Click this link to create a new server... 


Fig. 2.10: Clique no link de criação de servidores 


BOLD qu New Server 


Define a New Server 
Choose the type of server to create 


nt additional server adapters 














Select the server type: 
“type filter text x) 
=] JBoss AS 3.2 
© JBoss AS 4.0 
É JBoss AS 4.2 
{| JBoss AS 5.0 
ã JBoss AS 5.1 
EE] JBoss AS 6.x 
ã JBoss AS 7.0 
& JBoss AS 7.1 


WildFly Application Server 8.x 

















Server's host name: y localhost g | 





Server name: | WildFly 8.x 








D < Back | Next> | | Cancel | [Finish | 


Fig. 2.11: Selecione o WildFly, e clique no menu Jboss Comunity 
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Casa do Código 
sono New Server 
Ld 
Create a new Server Adapter a y . 
WildFly Application Server 8.x e JBoss 
@ @ by RedHat 





A Server Adapter manages starting and stopping instances of your server. It manages command line 
arguments and keeps track of which modules have been deployed. 


The server is: © total 
C) Remote 


Controlled by: © Filesystem and shell operations 


(_) Management Operations 
|_| Server is externally managed. Assume server is started. 


The selected profile requires a runtime. 


V Assign a runtime to this server 





| Create new runtime (next page) > 


= 





Runtime Details 


JRE: 

Home Directory: 
Base Directory: 
Configuration File: 





?) | 





<Back | [| Next> | | Cancel | 


Finish 


Fig. 2.12: Deixe tudo no valor default 


Casa do Cédigo 
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| D e Edit Server Runtime Environment | 
JBoss Runtime 


e s 
e JBoss 
WildFly Application Server 8.x 


& 
% o by Red Hat 





A JBoss Server runtime references a JBoss installation directory. 
It can be used to set up classpaths for projects which depend on this runtime, 
as well as by a “server* which will be able to start and stop instances of JBoss. 


Name 


Home Directory Download and install runtime... 


| /Users/alberto/ambiente/servidores/wildfly-8.2.0.Final-livro 


Browse... 
Runtime JRE 
_ Execution Environment: JavaSE-1.7 Š ___ Environments... | 
© Alternate JRE: Java SE8 [1.8.0490] B installed JREs.. =| | 





Configuration base directory: standalone 








Browse... 
Configuration file: | standalone-full.xmi Browse... 
2) “Cancel | MEO | 


Fig. 2.13: Aponte para o caminho de instalação e use o standalone-full.xml 


Para que esse passo seja possível, você deve realizar o download do Wild- 


fly, que pode ser encontrado em http://wildfly.org/downloads/. Pegue a ver- 
são 8.2.0.Final. 
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VERSÕES DO WILDFLY 


A partir da versão 8.x, o WildFly começou a implementar a especifi- 
cação do Java EE 7. Durante o livro, vamos usar a própria versão 8, mas 
fique a vontade para testar novas versões que também implementam a 
especificação do 7. Tudo deve funcionar normalmente. 











Além disso, o wizard pede que nós utilizemos o arquivo de configuração 
chamado standalone.xml. O problema é que ele não carrega todos os 
módulos da especificação que serão necessários para o desenvolvimento da 
aplicação. Por exemplo, mesmo não sendo importante agora, mais à frente 
no livro será usado um recurso chamado de mensageria, que não está confi- 
gurado neste arquivo. 

Para evitar ter de começar alterando um arquivo e depois ter de utilizar 
outro, já troque essa opção pelo standalone-full.xml. Por fim, adicione 
o projeto no servidor. 


22 


Casa do Código Capítulo 2. Começando o projeto 


E 





ana New Server 





Add and Remove 


Modify the resources that are configured on the server 





Move resources to the right to configure them on the server 


Available: Configured: 





[b casadocodigo 


e) j <Back | Next | Cancel {Finish 


Fig. 2.14: Adicione o projeto no servidor 


Associe um servidor ao projeto 


Vamos precisar das APIs do Java EE que estão disponíveis dentro do ser- 
vidor. Até agora, temos usado o Forge para configurar e adicionar as depen- 
déncias necessárias dentro do nosso pom.xml, para que possamos compilar 
nosso código. Isso é útil apenas quando outros arquivos precisam ser gerados. 

Durante vários momentos, vamos precisar apenas ter acesso às interfaces 
da especificação. Para garantirmos que só vamos usar o Forge quando real- 
mente for necessário, vamos adicionar as 1ibs disponíveis no Wildfly dentro 
do nosso projeto. 
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[8 Package Explo Open Type Hierarchy F4 
Pe casadocod Show In NEW > 
> GBsrc/mair [E Copy gC 
a to E Copy Qualified Name 
EBsrejtest) [E Paste #V 
> SÌÀJRE Syste 4 Delete & 
P Ei Maven D 
> Ea src Build Path , Link Source... 
> ae Source NES > &% New Source Folder... 
insert-at_ Refactor XT > 
[oj pom.xml g Use as Source Folder 
ùs Import... fm Add External Archives... 
ia Export... Add Libraries... 
£ Refresh F5 & Configure Build Path... 
Close Project — o 





Fig. 2.15: Menu de alteração do Build Path 





'Connectivity Driver Definition 
'CXF Runtime 

EAR Libraries 

J2EE 1.3 libraries 

J2EE 1.4 libraries 

Java EE 5 libraries 

JBoss EJB3 Libraries 

JRE System Library 

JUnit 

Maven Managed Dependencies 
Plug-in Dependencies 

Server Runtime 
TestNG 

User Library 

Web App Libraries 





2) < Back [Nexe] | Cancel | Finistt 





Fig. 2.16: Server Runtime libraries 
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ano Add Library 
Server Library 


Select a server runtime to add to the classpath 





Select a runtime to add to the classpath: 


5 WildFly 8.x Runtime 

















Fig. 2.17: Selecione o WildFly 


2.2 ACESSANDO O PRIMEIRO ENDEREÇO 


Com tudo configurado, chegou a hora de realmente começarmos a produzir 
alguma coisa! O nosso primeiro desafio é levar o usuário para a tela de cadas- 
tro de livros da Casa do Código. O endereço que queremos que ele digite é o 
/produtos/form.xhtml. 

Neste momento, caso o usuário digite http://localhost:8080/casadocodigo/ 
produtos/form.xhtml, ele receberá um erro do servidor indicando que esse en- 
dereço não pode ser atendido por ninguém. 

Então, por mais óbvio que isso pareça, precisamos criar uma página 
que fique acessível pelo navegador. Podemos criar uma pasta chamada 
produtos dentro de WebContent e, lá dentro, criamos o arquivo chamado 
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form.xhtml. 


<html xmlns:h="http://java.sun.com/jsf/html"> 
<h: body> 
<h: form> 
<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h: inputText/> 
</div> 
<div> 
<h:outputLabel>Descrição</h: outputLabel> 
<h: inputTextarea cols="20" rows="10"/> 
</div> 
<div> 
<h:outputLabel>Número de paginas</h: outputLabel> 
<h: inputText/> 
</div> 
<div> 
<h: outputLabel>Prego</h: outputLabel> 
<h: inputText/> 
</div> 
<h:commandButton value=" Gravar'"/> 
</h:form> 
</h:body> 
</html> 


Aqui, já usamos algumas tags do JSF que foram importadas por meio do 
namespace http://java.sun.com/jsf/html. Agora, caso o mesmo endereço seja 
acessado, recebemos uma resposta estranha. 
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e Cc localhost:8080/casadocodigo/ produtos /form.xhtml Tel EI = 





This XML file does not appear to have any style information associated with it. The document tree is shown below. 


v<html xmins:h="http://java.sun.com/jsf/html"> 
v<h:body> 
v<h: form> 
v<div> 
<h:outputLabel>Nome</h :outputLabel> 
<h: inputText/> 
</div> 
v<div> 
<h:outputLabel>Titulo</h;outputLabel> 
<h: inputText/> 
</div> 
v<div> 
<h:outputLabel>Descrição</h:outputLabel> 
<h: inputTextarea cols="20" rows="10"/> 
</div> 
<h:commandButton value=" Gravar"/> 
</h: form> 
</h:body> 
</html> 


Fig. 2.18: Navegador interpretou um XML comum 


Perceba que as tags que usamos do JSF nem foram interpretadas. Como 
pedimos por um endereço que termina com xhtml, o Wildfly entendeu que 
realmente está sendo solicitado um simples documento XML, e não uma pá- 
gina que precisa ser processada para a geração de HTML. 

Vamos fazer uma simples alteração. Em vez de terminar com xhtml, 
vamos fazer com que o endereço termine com .jsf. E agora, como um 
passe de mágica, foi exibida a página corretamente. A pergunta intrigante é: 
como isso aconteceu? 


Já está tudo configurado! 


O Wildfly já possui a implementação do JSF; no caso, está sendo usada 
a Mojarra sem nós precisarmos fazer nada, nem adicionar um web.xml. O 
servlet do JSF já foi configurado. 

Um outro bom questionamento é: só porque estou dentro de um servidor 
de aplicação, quer dizer que vou usar o JSF como framework MVC? Perceba 
que essa seria uma suposição um tanto quanto presunçosa dos servidores. 
Na verdade, meio que sem saber, informamos ao servidor que nosso projeto 
gostaria de habilitar o JSF. 
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Lembra do arquivo faces-config.xm1? Quando um servidor de apli- 





cação o encontra na pasta WEB-INF, automaticamente assume que a aplica- 
ção quer usar JSF, e o seu servlet é configurado. 

Voltando à extensão .jsf, ela é apenas uma das opções de 
url-pattern criadas por padrão. 


e /faces - http://localhost:8080/casadocodigo/faces/produtos/form. 
xhtml 


e x. jsf — http://localhost:8080/casadocodigo/produtos/form.jsf 


e x. faces - http://localhost:8080/casadocodigo/produtos/form.faces 


Perceba que sempre temos de passar o caminho para o arquivo, o que 
muda são as maneiras como passamos. 

O engraçado é que, por mais que essas sejam as convenções, nenhuma de- 
las é usada pela maioria das empresas no mercado. É muito comum encontrar 
o servlet do JSF configurado para o url-pattern x.xhtml. Para ficarmos 
próximos do que você vai encontrar no seu próximo emprego, vamos realizar 
essa alteração. 

Primeiro, é necessário que o arquivo web.xml seja gerado. Para isso, 
vamos utilizar o próprio Eclipse. Clique com o botão direito em cima do 
nome do projeto, e escolha a opção Properties. 


Maven 
Java EE Tools za Update EAR Libraries 
Configure E 
& Cenerate Deployment Descriptor Stub 
TestNG >» — — 





Fig. 2.19: Gerador de web.xml 


No arquivo gerado, adicione a nova configuração do Servlet. 


<?aml version="1.0" encoding="UTF-8"?> 
<web-app ...> 
<display-name>casadocodigo</display-name> 
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<servlet> 
<servlet-name>jsf</servlet-name> 
<servlet-class> 
javax.faces.webapp.FacesServlet 
</servlet-class> 
</servlet> 
<servlet-mapping> 
<servlet-name>jsf</servlet-name> 
<url-pattern>*.xhtml</url-pattern> 
</servlet-mapping> 


</web-app> 


Pronto, agora você pode acessar o endereço previamente combinado, que 
tudo funcionará normalmente. 


2.3 UM POUCO POR DENTRO DO FRAMEWORK 


Um ponto que muitas vezes diferencia “usuários” do framework de “entende- 
dores” é justamente ter o conhecimento do que acontece por dentro da ferra- 
menta. Por exemplo, como o JSF registra o Servlet dele automaticamente? 
Foi explicado que ele analisa a existência do arquivo faces-config, mas 
onde isso é feito? Onde está o código de carregamento da FacesServlet? 

Essas são perguntas que, por mais que não tenham a ver com o seu código 
de negócio em si, podem ser importantes para entender o fluxo do framework. 


O web.xml é desnecessário! 


Desde a versão 3 da especificação, não é mais necessário ter o arquivo 
web. xml para realizar a configuração de servlets e filtros. Uma das opções 





é declarar um arquivo chamado web-fragment dentro da pasta META-INF 
e empacotar como um jar. O projeto que adicionar essa 1ib já vai ganhar 
de brinde as configurações contidas dentro do fragment. 

Outra opção usada pelo JSF é a de registrar um listener 
que é chamado quando o servidor acaba de subir. Dentro do 
jar da implementação do JSF existe um arquivo com o nome 
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javax.servlet.ServletContainerInitializer, localizado na 





pasta META-INF/services. Quando o servidor sobe, ele analisa esse 
arquivo e carrega qualquer classe que esteja configurada dentro dele. No caso 
do JSF, a classe éa FacesInitializer. 

Agora vamos dar uma olhada, apenas por curiosidade, na implementação 
dessa classe. 


public void onStartup(Set<Class<?>> classes, 
ServletContext servletContext) 
throws ServletException { 


if (shouldCheckMappings(classes, servletContext)) { 
InitFacesContext initFacesContext = new 
InitFacesContext (servletContext) ; 
if (mull == initFacesContext) { 
throw new 
ServletException("Unable to initialize Mojarra"); 


} 


Map<String,? extends ServletRegistration> existing = 
servletContext.getServletRegistrations () ; 
for (ServletRegistration registration : 
existing.values()) { 
if (FACES_SERVLET_CLASS. 
equals (registration. getClassName())) 1 
// FacesServlet has already been defined, 
// so we’re not going to add 
// additional mappings; 


return; 


} 
ServletRegistration reg = 
servletContext.addServlet ("FacesServlet", 
"javax.faces.webapp.FacesServlet") ; 
reg.addMapping("/faces/*", "*.jsf", "*.faces"); 
servletContext.setAttribute(RIConstants. 
FACES_INITIALIZER_MAPPINGS_ADDED, 
Boolean. TRUE); 
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private boolean shouldCheckMappings 
(Set<Class<?>> classes, ServletContext context) { 


if (classes != null && !classes.isEmpty()) { 
return true; 


try À 
return 
(context .getResource("/WEB-INF/faces-config.xml") 
l= null); 

} catch (MalformedURLException mue) { 


return false; 


Perceba que o método shouldCheckMappings verifica a existência do 
arquivo faces-config.xml. 


O trecho que segue é o responsável por decidir seo servlet deve ser 
registrado automaticamente. 


for (ServletRegistration registration : existing.values()) { 
if (FACES SERVLET CLASS. 
equals(registration.getClassName())) 1 
// FacesServlet has already been defined, so we're 
// not going to add additional mappings; 
return; 


} 
ServletRegistration reg = 
servletContext.addServlet ("FacesServlet", 
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"javax.faces.webapp.FacesServlet") ; 
reg.addMapping("/faces/*", "*.jsf", "*.faces"); 


Ele procura por um mapeamento do servlet e, caso nao tenha, faz o 
registro programático. Por sinal, perceba que os url-patterns criados são 
justamente os que comentamos anteriormente. 





POSSÍVEL PROBLEMA COM OS COOKIES 


O JSF faz uso do escopo de session para implementar detalhes inter- 
nos, como manter a árvore de componentes (vamos voltar a ela mais à 
frente). Caso você tenha outras aplicações no seu computador que tam- 
bém fazem uso da sessão, é bem provável que você acabe com vários co- 
okies associados à chave jsessionid no seu navegador. 

Nesse cenário, muitas vezes o JSF se perde, não conseguindo associar 
corretamente a requisição com a árvore de componentes. Para não pas- 
sar por problemas desnecessários, minha sugestão é que você limpe os 
cookies associados ao localhost no seu navegador. 











2.4 CONCLUSÃO 


Este capítulo foi um pouco longo e, para ser bem sincero, até simples. O pro- 
blema é que foi necessária muita explicação para um simples hello world. A 
parte boa dessa história é que você passou por uma das etapas mais difíceis 
no aprendizado de qualquer projeto: o setup inicial. 

Agora, tudo tende a ser mais fluido! Por isso, eu indico que você continue 
a leitura. Nos próximos capítulos, já começaremos a acessar o banco de dados 
para cadastrar e listar os produtos da loja. 
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Cadastro de produtos 


Passada a fase de configuração, chegou a hora de começarmos a implementar 
algumas das funcionalidades da loja. Uma das features mais básicas, porém 
importante, é o cadastro de livros, já que sem livros não existem compras. O 
legal é que já começamos um pouco disso no capítulo anterior, então vamos 
apenas dar continuação. 


3.1 FORMULÁRIO DE CADASTRO 


Vamos reaproveitar o formulário que usamos como hello world do nosso pro- 
jeto para começar a criar a tela de cadastro. 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:jsf="http://xmlns.jcp.org/jsf'> 
<h: body> 


3.1. Formulário de cadastro Casa do Código 





<h:form> 
<div> 
<h:outputLabel>Titulo</h: outputLabel> 
<h: inputText/> 
</div> 
<div> 
<h:outputLabel>Descrição</h: outputLabel> 
<h: inputTextarea cols="20" rows="10"/> 
</div> 
<div> 
<h:outputLabel>Número de páginas</h:outputLabel> 
<h: inputText/> 
</div> 
<div> 
<h:outputLabel>Preço</h:outputLabel> 
<h: inputText/> 
</div> 
<h: commandButton value=" Gravar'"/> 
</h:form> 
</h: body> 
</html> 


Nao tem nada de mais, apenas um HTML normal com algumas tags do 
JSF. Só para constar, nosso modelo de livro não precisa ser muito complexo. 
Ele terá apenas um título, descrição, número total de páginas e preço, pelo 
menos por enquanto. 

Um detalhe importante que ficou faltando: para onde vamos enviar as 
informações cadastradas? Ainda não criamos nada que trate essa lógica. 
Como o JSF tenta trazer para o mundo web uma programação parecida com 
o mundo desktop, temos de adicionar um método que deve ser chamado após 
o formulário ser submetido. 

Para começarmos a implementação dessa lógica, vamos alterar o nosso 
commandButton para que ele referencie o método que deve ser invocado. 


<h:commandButton value="Gravar" action="#{adminBooksBean.save}"/> 
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3.2 LÓGICA DE CADASTRO 


Agora, se você tentar cadastrar um novo livro, vai receber a seguinte 


exception: 


javax.servlet.ServletException: 
javax.el.PropertyNotFoundException: 

/produtos/form.xhtml 017,69 action="#{adminBooksBean.save}": 

Target Unreachable, identifier ’adminBooksBean’ resolved to null 


Ela indica que a expression language nao conseguiu resolver a referéncia 
para a variável adminBooksBean. Essa será justamente a primeira classe 
que vamos criar, para que possamos começar a implementar o cadastro no 


nosso sistema. 


package br.com.casadocodigo.loja.managedbeans ; 


@Model 
public class AdminBooksBean { 
public void save(){ 
System.out.printin("Precisamos salvar o livro!!"); 


Agora, quando apertamos o botão, a mensagem ja é impressa no console 
do nosso servidor. Um ponto importante aqui é o uso da annotation @Model. 
Ela é uma annotation do CDI que indica que os objetos da classe por ela ano- 


tada sempre serão criados no escopo de request, e ficarão disponíveis para 





serem acessados pela Expression Language. 

Por padrão, o nome da variável cujo objeto ficará acessível é o mesmo 
nome da classe, com a primeira letra em minúsculo. Esse é um caso bem 
comum para uma aplicação web, na qual, em geral, queremos criar novos 
objetos a partir de cada requisição. 

Voltando para nossa funcionalidade, precisamos pelo menos imprimir as 
informações de cadastro que foram preenchidas pelo usuário. Para fazer isso, 
é necessário associar cada um dos campos do nosso formulário a uma pro- 
priedade. 
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<h:form> 
<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h: inputText value="#{adminBooksBean.product.title}" /> 
</div> 
<div> 
<h: outputLabel>Descrig&o</h: outputLabel> 
<h: inputTextarea cols="20" rows="10" 
value="#{adminBooksBean.product.description}" /> 
</div> 


<div> 
<h:outputLabel>Número de paginas</h: outputLabel> 
<h: inputText 
value="#{adminBooksBean.product .number0fPages}" /> 
</div> 


<div> 
<h: outputLabel>Prego</h: outputLabel> 
<h:inputText value="#{adminBooksBean.product.price}" /> 
</div> 
<h:commandButton value="Gravar" 
action="#{adminBooksBean.save}" /> 
</h:form> 


Analise, por exemplo, a propriedade value do input referente ao titulo 
do livro. Estamos dizendo que a classe AdminBooksBean possui um método 
chamado getProduct, e que este retorna um objeto que possui um getter 
e um setter para a propriedade title. Dessa forma, o JSF consegue nave- 
gar pelas propriedades dos beans, também conhecidos no mercado como 
Managed Beans, e popular os referidos campos. 

Agora, para fazer esse código funcionar, precisamos implementar as par- 
tes que faltam no nosso código. Inicialmente, vamos criar a classe que repre- 
senta o nosso livro. 


package br.com.casadocodigo.loja.models; 


//imports 


36 


Casa do Cédigo Capítulo 3. Cadastro de produtos 





public class Book { 


private Integer id; 

private String title; 
private String description; 
private int number0fPages; 
private BigDecimal price; 


//getters e setters 
//adicione um toString interessante. 


Agora, precisamos realizar as alterações necessárias na classe 


AdminBooksBean. 


public class AdminBooksBean { 
private Book product = new Book(); 
public void save(){ 


System.out.printin(product); 


public Book getProduct() { 
return product; 


Caso você realize um novo teste na aplicação, deverá ver as informações 
que foram passadas pelo usuário. 
Reflexão sobre como a requisição é feita 


Esse é um bom momento para pensarmos um pouco em como as coisas 
acontecem dentro de uma aplicação JSF. Na web tradicional, somos acostu- 
mados a dar nomes para os inputs, e pegar os valores associados a estes nomes 
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do lado do servidor. Só que pare e olhe para o nosso formulário: onde estão 
os nomes? Toda a associação é realizada por meio do atributo value, dispo- 
nível nas tags do próprio JSF. 

Quando utilizamos o JSF, para cada tela carregada, é construída uma ár- 
vore de componentes representando cada um dos elementos que escrevemos 
na página. Tanto é que, se você olhar o código-fonte que aparece no seu na- 
vegador, encontrará algo assim: 


<input type="hidden" name="javax.faces.ViewState" 
id="j idi:javax.faces.ViewState:0" 
value= 
autocomplete="off'! /> 


Esse é o id que foi dado para a árvore criada. Agora, todas as vezes em 
que realizarmos um post por meio do nosso formulário, o id será mantido, 
pelo menos enquanto não fizermos nenhum redirect. 

Experimente acessar novamente o endereço do formulário em vez de sub- 
meter os dados do form. Você verá que o id vai mudar. Para ir mantendo 
o estado dos valores dos inputs do lado do servidor, o JSF guarda a árvore na 
sessão do usuário. 

Agora, você pode se perguntar: para que serve esse id, já que ele mantém 
o estado da árvore na sessão? Esse é um ótimo questionamento! O problema 
é que, se você abrir várias abas no seu navegador e, como a sessão continu- 
ará sendo a mesma, o framework vai precisar distinguir sobre qual árvore o 
request está falando. 

É por conta desse mecanismo que os valores que você preencheu no for- 
mulário para realizar os testes continuaram nos inputs, mesmo depois de você 
ter feito a requisição. Em uma aplicação web normal, esses valores teriam de- 
saparecido. É também por conta disso que você não precisa colocar nomes 
nos inputs, nem actions nos formulários, tudo é associado no momento em 
que ele constrói a árvore de componentes. 


3.3 GRAVANDO OS DADOS NO BANCO DE DADOS 


Por mais que nosso formulário já esteja um tanto quanto funcional, ainda não 
estamos efetivamente gravando as informações passadas. Para melhorar essa 
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parte, vamos começar a efetuar as alterações necessárias a partir do nosso 
controller. 

A primeira coisa é começar a usar um DAO (Data Access Object) respon- 
sável pelo acesso aos dados referente à classe Book. 





LEMBRETE SOBRE O DAO 


O Data Access Object é apenas uma classe cujo objetivo é isolar o 
acesso aos dados de um determinada parte do sistema. No nosso exem- 
plo, vamos precisar gravar, listar e carregar um livro. Não queremos mis- 
turar essa parte de acesso à infraestrutura com nossas lógicas. 











O código do método save deve ficar parecido com o que segue: 


public void save Ot 
bookDAO. save(product) ; 


E de onde vem essa instância da classe BookDAO? Uma das opções é que 
nds mesmos criemos esse objeto na mao. 


@Model 
public class AdminBooksBean { 


private Book product = new Book(); 
private BookDAO bookDAO = new BookDAO(); 


public void save(){ 
bookDAO. save (product); 


O problema é que, provavelmente, o construtor do BookDAO vai precisar 
receber algum objeto que represente a conexão com o banco de dados e, nesse 
caso, vamos ter de começar a controlar essas dependências na mão. Essa é 
uma ótima parte para usarmos mais do CDI no nosso projeto. 
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Como a nossa classe já é gerenciada pelo CDI, podemos pedir para que ele 
instancie um novo objeto do tipo BookDAO para nós. O nosso único trabalho 
é indicar que precisamos receber essa instância injetada. 


@Model 


public class AdminBooksBean { 


private Book product = new Book(); 
@Inject 
private BookDAO bookDAO; 


public void save(){ 
bookDAO. save (product) ; 


public Book getProduct() { 
return product; 


A annotation @Inject é justamente a responsável por indicar os pontos 
de injeção dentro da sua classe. Esse é um bom momento para lembrá-lo 
de que, em um projeto usando CDI, a única configuração necessária para 
habilitar o scan de classes é a criação do arquivo beans . xml, dentro da pasta 
WEB-INF. 








PARA QUE SERVE UM ARQUIVO EM BRANCO? 


É um ótimo questionamento, mas lembre: o arquivo está lá para habi- 
litar seu projeto para ser scaneado pelo Weld, que é a implementação do 
CDI usada dentro do WildFly. Caso não fosse necessário criá-lo, o Weld 
teria de ir olhando dentro de cada classe de cada jar do seu projeto 
para descobrir quais classes gostariam de ser gerenciadas ou não. Dessa 
forma, ele primeiro busca pela existência do arquivo e, apenas em caso 
positivo, dá prosseguimento pela busca por classes. 
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Nesse exato momento, nosso código não compila, já que não criamos 
ainda a classe BookDAO, assim como não existe o método save. Chegou 
a hora de resolvermos essa parte do nosso código. 


package br.com.casadocodigo.loja.daos; 


import javax.persistence.EntityManager; 
import javax.persistence.PersistenceContext; 


import br.com.casadocodigo.loja.models.Book; 


public class BookDAO { 


@PersistenceContext 
private EntityManager manager; 


public void save(Book product) { 
manager .persist (product) ; 


Aqui estamos usando a JPA para realizar a parte de acesso efetivo ao nosso 
banco de dados. Na próxima seção, trataremos sobre como configurá-la. 

Voltando ao nosso BookDAO, perceba que ela é uma classe bem normal. 
Não foi necessária nenhuma configuração extra, e essa é uma das belezas do 
CDI. 

Até podemos usar annotations, como foi o caso na classe 
AdminBooksBean, mas várias vezes não precisamos adicionar nenhuma 
delas. Neste caso específico, você pode estar se perguntando: qual é o escopo 
da criação desse objeto? 

Quando não colocamos nenhuma anotação em cima da classe, estamos 
dizendo que, na verdade, quem decide o escopo do objeto é o local onde ele 
vai ser injetado. Observe o exemplo: 


@Model 
public class AdminBooksBean { 
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@Inject 
private BookDAO bookDAO = new BookDAO(); 


Como já vimos, a annotation @Mode1 indica que os objetos da classe ano- 
tada devem viver pelo tempo de uma requisição web e, além disso, também 
devem ficar expostos na expression language. Como a classe BookDAO não 
definiu o escopo explicitamente, o tempo de vida do seu objeto, nesse caso, 
vai ser o da duração de um request, já que a classe que solicitou sua injeção 
definiu este escopo. 

Caso tivéssemos pedido essa injeção em uma classe de escopo session, o 
objeto do tipo BookDAO teria assumido o mesmo. Essa estratégia dentro do 
CDI é chamada de escopo @Dependent. Não adicionar nenhuma anotação 
de tempo de vida é o mesmo que fazer o seguinte: 


@Dependent 
public class BookDAO { 


Várias vezes, em uma aplicação web, o @Dependent vai ser o perfeito 
para você. Como quase tudo começa a partir do seu Managed Bean, que é 
criado uma vez por requisição, todos os outros objetos automaticamente vão 
seguir o mesmo tempo de vida. 


3.4 CONFIGURANDO A JPA 


Estamos quase conseguindo gravar o produto, só falta agora configurarmos 
a JPA (Java Persistence API) para que nosso acesso ao banco de dados fique 
completo. Para fazer isso, precisamos seguir alguns passos. 
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Mapeando a entidade 


Chegou a hora de fazermos as configurações necessárias para que os ob- 
jetos da classe Book possam ser salvos. Um passo importante é ensinar a 
implementação da JPA - em nosso caso, o Hibernate - que a classe Book vai 
representar uma tabela no banco de dados. 


import javax.persistence.Entity; 


CEntity 
public class Book { 


@Id @GeneratedValue (strategy=GenerationType. IDENTITY) 
private Integer id; 

private String title; 

private String description; 

private int number0fPages; 

private BigDecimal price; 


Aqui usamos algumas annotations especificas da JPA para realizar esses 


ensinamentos: 


e 
D 





Entity - indica que a classe vai virar uma tabela; 


e GId - indica que o atributo em questão é a chave-primária; 





* @GeneratedValue - indica a maneira como vai ser gerada a chave- 


primária; 


e @Lob — indica que o atributo em questão vai ser salvo como Clob ou 
Blob no banco de dados. 


Não acho que vale a pena entrarmos em todos os mapeamentos possíveis 
da JPA. O nosso foco durante o livro é construir uma aplicação web tirando 
proveito de todas as especificações que nos sejam úteis. Nesse contexto, a JPA 


é apenas mais uma delas. 
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@PersistenceContext e o Persistence.xml 


Uma annotation que passou batida no nosso debate anterior foi a 
@PersistenceContext. Ela é utilizada para indicar, dentro de um con- 








tainer Java EE, a necessidade de injeção de um EntityManager que seja 
controlado e criado pelo próprio servidor. O legal dessa annotation é que 
sua semântica é muito forte, então, várias outras tecnologias, como o Spring, 





fazem seu uso para indicar a injeção de um EntityManager. 

Um outro ponto importante são as informações de acesso ao banco 
de dados. A especificação JPA indica que devemos utilizar um ar- 
quivo chamado persistence.xml, e que nele devem estar contidas 
nossas informações de acesso ao banco de dados. Este arquivo deve 





ser criado na pasta META-INF, dentro do build path do seu projeto. 
Em projetos que usam Maven, como é o nosso caso, o caminho será 








src/main/resources/META-INF/persistence.xml. 


<?aml version="1.0" encoding="UTF-8" standalone="yes"?> 
<persistence xmlns="http://xmlns. jcp.org/xml/ns/persistence" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
version="2.1" 
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence 
http: //xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"> 


<persistence-unit name="casadocodigo-dev" 
transaction-type="JTA"> 
<description>Dev persistence unit</description> 
<provider> 
org. hibernate.ejb.HibernatePersistence 
</provider> 
<jta-data-source> 
java: jboss/datasources/casadocodigoDS 
</jta-data-source> 
<properties> 
<property name="hibernate.hbm2dd1.auto" 
value="update"/> 
<property name="hibernate.show_sql" 
value="true" /> 
<property name="hibernate.format sql" 
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value="true" /> 
<property name="hibernate.dialect" 
value="org.hibernate.dialect 
.MySQL5InnoDBDialect"/> 
</properties> 
</persistence-unit> 
</persistence> 


Perceba que fizemos algumas configurações específicas do Hibernate, 
como a propriedade hibernate.hbm2ddl.auto. Ela é usada para que 
não precisemos ficar criando tabelas novas no banco todas as vezes em que 
mapeamos uma nova entidade. 

Uma outra tag interessante é a <provider>, necessária para informar 
qual implementação da JPA será utilizada no projeto. No nosso caso, como 
estamos dentro do WildFly, será usado o Hibernate. 

Um ponto que você pode estar se perguntando é onde estão as configu- 
rações de acesso ao banco de dados em si. Sempre que vamos nos conectar, 
somos obrigados a informar coisas como: 


e URL de acesso ao banco; 
e Login; 
e Senha; 


e Driver necessario. 


E você esta coberto de razão, isso tudo é necessário. A única diferença é 
que vamos tirar proveito de toda a infraestrutura provida pelo nosso servidor 
de aplicação. Em vez de realizarmos essas configurações e deixarmos a cargo 
do Hibernate gerenciar as nossas conexões, vamos pedir para que o WildFly 
crie e gerencie-as. Dessa forma, a única tarefa do Hibernate será a de pedir 
uma nova conexão sempre que necessário. 


Esse é justamente o objetivo da seguinte linha de configuração: 


<jta-data-source> 
java: jboss/datasources/casadocodigoDS 
</jta-data-source> 
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Simplesmente passamos um nome que esta associado a um 
DataSource, que será configurado dentro do próprio servidor. Se- 
gure um pouco a curiosidade agora, na próxima seção discutiremos mais 
sobre esse nome. Ainda precisamos parar e pensar sobre a sigla JTA (Java 
Transaction API), que apareceu no nome dessa tag e também na propriedade 
transaction-type. Tudo isso será desvendado ainda neste capítulo. 


3.5 CONFIGURAÇÃO DO DATASOURCE NO WILDLFLY 


Precisamos completar nossa configuração de acesso ao banco de dados, 
e o ponto que ficou faltando foi justamente a configuração relativa do 
DataSource. Aqui, vale a pena ressaltar que essa configuração vai variar 
entre os servidores de aplicação que você decidir usar. 


Arquivo de configuração do WildlFly 


O arquivo responsável pelas configurações do nosso WildFly, 
nesse momento, é o standalone-full.xml. Ele fica na pasta 
caminhoInstalacaoWildfly/standalone/configuration/ 
standalone-full.xml. 

O nome standalone vem do fato de estarmos rodando apenas uma ins- 
tância do servidor. Ele também suporta uma outra maneira de execução, na 
qual subimos várias instâncias do servidor e fazemos com que elas se com- 
portem como se fossem apenas uma, modo conhecido como Cluster Mode. 

Caso você esteja curioso e tenha navegado até a pasta configuration, 
verá que lá dentro existem outros arquivos de configurações. Esta é uma das 
grandes vantagens do WildFly: sua modularização. Podemos definir quais 
módulos são necessários para a nossa aplicação. Por exemplo, no caso do 
standalone-full.xml, recebemos pronto tudo de que normalmente po- 
demos precisar. 


e JPA; 
e E-mail; 


e JSF; 
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Transações (JTA); 


Weld (CDI); 


Servlets; 


e WebServices; 


e EJB. 


Perceba que já são várias opções. Há alguns itens dessa lista que já estu- 


damos, alguns que você ja deve saber - como a parte de Servlets -, e ainda 


outros que vamos trabalhar durante o livro. Além destes, ainda vamos usar 


uma outra especificação, que é a de mensageria, mas isso é assunto para ser 


visto mais para a frente. 


Para exemplificar melhor, analise o trecho do arquivo que contém essas 


configurações: 


<extensions> 


<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 
<extension module="org.jboss. 


</extensions> 


as. 


as. 


as. 


as. 


as. 


as. 


as. 


as. 


as. 


as. 


clustering. infinispan"/> 
connector" /> 
deployment-scanner"/> 
ee" /> 

ejb3"/> 

jaxrs"/> 

jdr"/> 

jmx"/> 

jpa"/> 

{er "/> 


Voltando ao nosso trabalho de configuração do DataSource, é justa- 


mente do arquivo standalone-ful1l.xml que vamos precisar alterar para 


realizar uma parte desse trabalho. 
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Adicionando mais um DataSource 


Caso você continue olhando o arquivo, vera que existe uma tag chamada 
datasources, que é justamente o local onde residem as configurações es- 
pecíficas de acesso ao banco de dados. Apenas por curiosidade, essa tag está 
dentro de uma outra chamada subsystem. Cada subsystem contém as 
configurações relativas às extensões mapeadas no início do arquivo. 

Perceba que, dentro da tag datasources, já existe a configuração de 
um DataSource, justamente o que já vem pronto dentro do WildFly. Infe- 
lizmente, essa configuração usa o H2 como banco de dados, o que é não tão 
comum no mercado. Ele é mais utilizado para fins de testes. 


Pensando nisso, vamos configurar um outro DataSource para que pos- 


samos usar o MySQL. 


<datasources> 
<datasource> 


</datasource> 


<datasource 
jndi-name="java:jboss/datasources/casadocodigoDS" 
pool-name="casadocodigoDS"> 
<connection-url> 
jdbc:mysql://localhost:3306/casadocodigo 
</connection-url> 
<driver>mysql</driver> 
<security> 
<user-name>root</user-name> 
<!-- Caso precise de senha--> 
<password>sua-senha</password> 
</security> 
</datasource> 
</datasources> 


Perceba que a configuração é quase autoexplicativa. Algumas informa- 
ções são exatamente as mesmas com que já estamos acostumados. Veja: 


e <connection-url> — URL de conexão para sua base de dados; 
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e <security> -contém as informações de login e senha para o banco; 


Entretanto, existem algumas tags e atributos que merecem um pouco mais 
de atenção. O mais simples é o atributo pool-name. Ele representa o nome 
do pool de conexões que será criado para armazenar todas as conexões que 
forem criadas pelo nosso datasource. Caso você queira especificar mais 
informações sobre esse pool, pode usar a tag <pool>. Veja um exemplo a 
seguir, a configuração não é obrigatória. 


<datasource jndi-name="java: jboss/datasources/casadocodigoDS" 
pool-name="casadocodigoDS"> 
<connection-url>jdbc:mysql://localhost :3306/casadocodigo 
</connection-url> 
<driver>mysql</driver> 
<security> 
<user-name>root</user-name> 
</security> 
<pool> 
<min-pool-size>10</min-pool-size> 
<max-pool-size>20</max-pool-size> 
</pool> 
</datasource> 


Outro atributo, ainda na própria tag datasource, éo jndi-name. 
Nele, passamos o nome que deve ser referenciado pela aplicação, para que ela 
possa recuperar a referência para o objeto que representa o datasource. 

A JNDI é uma outra especificação do mundo Java que é muito utilizada. 
Quase todos os objetos que são criados pelo próprio container ficam dispo- 
níveis para serem acessados via algum nome que pode ser registrado. Quem 
faz todo o trabalho para buscar o objeto por esse nome é a implementação da 
especificação JNDI (Java Naming and Directory Interface). 

Ainda em relação à JNDI, é importante prestar atenção no início da String 
de definição do valor, começando com java: jboss/. Esse começo é o que 
informa o nível de disponibilidade dos objetos criados dentro do container, e 
é o que chamamos de namespace da JNDI. 

No caso do WildFly, para expor objetos que devem ser recuperados re- 
motamente, podemos trabalhar com os seguintes namespaces: 
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e java: jboss/ 
e java:/ 


Além dos atributos que discutimos - que estão presentes na própria tag 
datasource -, existe mais um detalhe bem relevante: a tag driver. Per- 
ceba que apenas colocamos o nome mysql. Mas como o container vai sa- 
ber qual classe deve ser usada para conectar neste banco? Do mesmo jeito 
que usamos banco MySQL, poderíamos ter usado o PostgreSQL. Caso você 
preste bastante atenção, verá que o mesmo ocorre na definição do driver do 
datasource anterior, com o H2. 


<datasource jndi-name="java: jboss/datasources/ExampleDS" 
pool-name="ExampleDS" enabled="true" 
use-java-context="true"> 
<connection-url>...</connection-url> 
<driver>h2</driver> 


</datasource> 


Ele também define apenas um nome do driver. 

Agora, vem um outro momento importante. Perceba que, logo abaixo 
das tags datasource, existe a declaração de uma tag chamada drivers. É 
justamente nela que uma parte deste misterioso nome começa a ser resolvida. 


<drivers> 
<driver name="h2" module="com.h2database.h2"> 
<xa-datasource-class>org.h2.jdbcx. JdbcDataSource 
</xa-datasource-class> 
</driver> 
</drivers> 


O nome informado na configuração do dat asource é apenas uma chave 
para o WildFly poder encontrar as configurações definidas na tag driver. 
Por exemplo, para o nosso exemplo com mysql, podemos adicionar outra 
tag. 


<drivers> 
<driver name="h2" module="com.h2database.h2"> 
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<xa-datasource-class>org.h2. jdbcx. JdbcDataSource 
</xa-datasource-class> 

</driver> 

<driver name="mysql" module="com.mysql"> 
<datasource-class> 

com.mysql.jdbc.Driver 

</datasource-class> 

</driver> 

</drivers> 


Agora, vou pedir um favor, nao fique chateado. Ainda precisamos realizar 
mais um passo para finalmente configurar nosso datasource. Com tudo 
isso pronto, falta apenas mais um detalhe: informar onde está o jar com as 
classes do driver do MySQL. E aqui o WildFly toma mais uma decisão. 

Várias vezes, as empresas querem definir uma versão padrão de certas 
bibliotecas, por exemplo, os drivers de acesso ao banco de dados. Para este 
tipo de caso, em alguns servidores, você simplesmente adiciona esses jars 
em uma pasta compartilhada. Por exemplo, no TomCat, isso ficaria na pasta 
lib do servidor. 

E se alguma aplicação precisar da versão atualizada do driver, como ela 
fará agora? Uma atualização pode impactar em várias outras aplicações. 

Para permitir o compartilhamento de jars entre aplicações, mas também 
com o pensamento de possibilitar a evolução das versões, o WildFly usou 
um esquema de modularização. Adicionamos os jars necessários dentro da 
pasta modules, que fica dentro da pasta de instalação do servidor. 
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Fig. 3.1: Estrutura de módulos do WildFly 


Perceba queo com.h2database.h2 coincidentemente é o caminho até 


a pasta main, onde existem o jar e um arquivo de configuração referente 
ao banco H2. Vamos dar uma olhada nesse arquivo. 


<module xmlns="urn: jboss:module:1.3" name="com.h2database.h2"> 


<resources> 
<resource-root path="h2-1.3.173.jar"/> 
</resources> 
<dependencies> 
<module name="javax.api"/> 
<module name="javax.transaction.api"/> 
<module name="javax.servlet.api" optional="true"/> 
</dependencies> 
</module> 


Não precisamos ficar debatendo sobre seu conteúdo. A parte mais impor- 
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tante para nós é o atributo name ea tag resources. 


e name - valor a ser referenciado por alguma configuração externa, como 
o driver. 


e resources - informa a localização dos jars necessários para que o 
módulo seja carregado. 


Precisamos criar algo parecido para a configuração do driver do MySQL. 
Então, dentro da pasta modules/system/layers/base/com, crie a se- 
guinte estrutura de pastas: mysql/main. Dentro da pasta main, crie o 
arquivo chamado module .xmi com o seguinte conteúdo: 


<?aml version="1.0" encoding="UTF-8"?> 
<module xmlns="urn: jboss:module:1.3" name="com.mysql"> 


<resources> 
<resource-root path="mysql-connector-java-5.1.35.jar"/> 
</resources> 
<dependencies> 
<module name="javax.api"/> 
</dependencies> 
</module> 


Para fechar, só precisamos do driver. Você pode baixá-lo em 
http://central.maven.org/maven2/mysql/mysql-connector-java/5.1.35/ 
mysql-connector-java-5.1.35.jar. 

Pronto! Agora com tudo configurado, você já pode iniciar o WildFly e 
tentar cadastrar um novo livro. 


Alterando o arquivo de configuração pelo Eclipse 


O arquivo de configuração do seu WildFly pode ser alterado diretamente 
por meio da navegação no sistema de arquivos, como foi mostrado durante o 
capítulo, assim como por dentro do seu Eclipse. 

Para fazer da segunda forma, que este autor acha mais simples, basta abrir 
aaba Servers e navegar diretamente até o arquivo. 
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Eb casadocodigo 
Y a Filesets 
¥ Configuration File Síjboss config dirt 
|X] standalone.xml 
+ (> Server Details 
® |X| XML Configuration 
® JMX[Disconnected] 


Fig. 3.2: Alterando o standalone.xml pelo Eclipse 


Você pode fazer todas as alterações necessárias a partir de agora, por meio 
da própria IDE. Durante o capítulo, essa forma não foi mostrada diretamente 
justamente para termos sempre em mente que é importante entender como 
as coisas funcionam, para não ficarmos presos à IDE. 


3.6 A NECESSIDADE DE UMA TRANSAÇÃO 


Quando tentamos gravar um novo livro, nesse momento, recebemos a se- 
guinte exception: 


javax.servlet.ServletException: 

javax.persistence. TransactionRequiredException: JBAS011469: 
Transaction is required to perform this operation 

(either use a transaction or extended persistence context) 


A exception é até bem clara, fala que precisamos de uma transação para 
conseguirmos salvar um objeto. Para a nossa sorte, lidar com transações já 
é suportado pela própria especificação Java EE. Assim, nosso único trabalho 
será fazer uma simples configuração. 


import javax.transaction.Transactional; 


@Model 
public class AdminBooksBean { 
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private Book product = 
@Inject 
private BookDAO bookDAO; 


@Transactional 
public void save(){ 
bookDAO. save (product) ; 


public Book getProduct() { 
return product; 


new Book(); 


A annotation @Transactional foi introduzida a partir do Java EE 7, 


e permite marcar que métodos gerenciados pelo CDI rodem dentro de um 


contexto transacional. Além disso, no inicio do capitulo, também fizemos 


uma leve configuração no arquivo persistence. xml. 


<persistence-unit name="casadocodigo-persistence-unit" 


transaction-type="JTA"> 
<jta-data-source> 


java: jboss/datasources/casadocodigoDS 


</jta-data-source> 
</persistence> 


Indicamos que quem vai cuidar das nossas transações é a JTA, justamente 


a especificação que cuida da parte de transações no Java EE. Também é por 


conta dessa especificação que usamos a tag <jta-data-source>, para in- 


formar que nosso DataSource deve ser criado de modo que as transações 


sejam gerenciadas pela JTA. 


Apenas por curiosidade, quando rodamos nossa aplicação em um ser- 


vidor de aplicação, o valor do atributo transaction-type já é JTA por 


padrão. Quando rodamos uma aplicação que usa a JPA dentro de outro am- 











biente, o valor default é RESOURCE LOCAL, que informa que o responsável 


por cuidar das transações é o próprio 





EntityManager 


Agora, finalmente, somos capazes de gravar os nossos livros! 
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Opiniao do autor sobre a JTA 


A Java Transaction API é uma especificação que vai bem além do que cui- 
dar de simples transações de banco de dados. Suas implementações suportam 
que várias operações sejam envolvidas na mesma transação, por exemplo: 


e Comunicação com banco de dados; 
e Comunicação com servidores de mensageria; 


e Comunicação com múltiplos bancos de dados na mesma transação. 


A possibilidade de termos todas essas operações envolvidas em uma 
mesma transação, por mais que exista, é baixa. Geralmente, este tipo de ce- 
nário pode ser encontrado em alguns bancos ou bolsas de valores. Algumas 
vezes, chega a ficar até mais complexo, com sistemas rodando em máquinas 
diferentes tendo de participar da mesma transação. 

Quando precisamos envolver múltiplos serviços na mesma transação, tra- 
balhamos com o conceito de transação distribuída, que já é suportado pela 
própria JTA. Drivers de banco de dados, por exemplo, suportam o conceito 
por meio da implementação da interface XAConnection. 

Dito isso, este autor não acha válido gastarmos muito tempo discutindo 
todas essas possibilidades da JTA, já que quase não temos contexto de uso para 
tais cenários. Ainda vamos voltar à JTA quando fomos discutir mensageria, 
controle mais fino sobre a transação corrente etc., que tendem a ser casos mais 
práticos e relevantes na maior parte da sua vida como desenvolvedor. 


3.7 CONCLUSÃO 


Neste capítulo, passamos por muita coisa. Foi necessária muita configuração 
para que nosso acesso ao banco de dados fosse possível. Só que o saldo po- 
sitivo de todo esse trabalho é que aprendemos mais sobre o WildFly e suas 
configurações. 

Por sinal, a configuração específica do servidor ainda é o “calcanhar de 
Aquiles” da especificação Java EE. Já temos muitos detalhes que funcionam 
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no automático, mas como muitas especificações têm relação com detalhes de 
infraestrutura, somos obrigados a realizar esses ajustes. 

A parte boa disso tudo é que conseguimos gravar nossos livros no banco 
de dados e, olhando apenas para o código, até que não tivemos nada com- 
plexo. A parte potencialmente mais complicada deste momento, que era o 
controle transacional, funcionou apenas com o uso de uma anotação. E essa 
é a parte que mais evoluiu na especificação, escrever código Java em si tem 
ficado muito fácil. 

No próximo capítulo, vamos evoluir o nosso cadastro, associando auto- 
res com os livros cadastrados, e listando e adicionando mensagens de confir- 
mação. Minha sugestão é que você não pare ainda. Venha comigo e vamos 
completar essa funcionalidade. 
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Melhorando o cadastro e um 
pouco mais de JSF 


Nosso cadastro de livros já começou a funcionar, só que está faltando uma ca- 
raterística bem importante: os autores dos livros. No site da Casa do Código, 
os livros podem ser escritos tanto por uma pessoa como por várias. 

Um caso bom para mostrar essa possibilidade é a página do li- 
vro Coletânea Front-end (http://www.casadocodigo.com.br/products/ 
livro-coletanea-front-end) . Ele foi escrito por diversas pessoas, e o nome de 
cada um é exibido dentro do site. 
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Coletanea Front-end: Uma 
antologia da comunidade front- 
end brasileira 


Almir Filho, Bernard De Luna, Caio Gondim, Deivid Marques, Diego Eis, 
Eduardo Shiota, Giovanni Keppelen, Luiz Corte Real, Jaydson Gomes, 
Reinaldo Ferraz e Sérgio Lopes 


Fig. 4.1: Imagem ilustrando os nomes dos autores 


Vamos começar a trabalhar na nossa aplicação para termos a mesma pos- 
sibilidade. 


4.1 ASSOCIANDO VÁRIOS AUTORES 


Nossa primeira tarefa vai ser preparar a nossa tela de cadastro para que o usuá- 
rio que administra a loja possa associar os autores. Para isso, vamos alterar o 


arquivo livros/form. xhtml. 


<div> 
<h: outputLabel>Autores</h: outputLabel> 
<h: selectManyListbox 
value="#{adminBooksBean.selectedAuthorsIds}"> 
<f:selectItems value="#{adminBooksBean.authors}" 
var="author" 
itemLabel="#{author.name}" itemValue="#{author.id}"/> 


</h:selectManyListbox> 
</div> 


Aqui foi necessário usar as tags se lectManyListboxe selectItems, 
para que possamos construir uma tag select do HTML com a possibilidade 
de escolha de vários itens. Mesmo que estejamos usando apenas algumas tags 
do JSF, já temos trabalho a ser feito. Por exemplo, de onde vem a listagem de 
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autores que precisamos exibir na tela? Qual lista vai ser preenchida com as 
informações selecionadas pelo usuário? 

Vamos por partes. Perceba que no atributo value 
da tag selectManyListbox  referenciamos a propriedade 
selectedAuthorsIds. É justamente a lista que vamos manter na 
nossa classe AdminBooksBean para podermos receber os IDs selecionados. 


@Model 
public class AdminBooksBean { 


private List<Integer> selectedAuthorsIds = 
new ArrayList<>(); 


// get e set para esse atributo. 


Sempre que um usuario selecionar os autores e tentar cadastrar um novo 


livro, vamos usar os ids escolhidos para associar os autores ao livro. 


@Model 
public class AdminBooksBean { 


private List<Integer> selectedAuthorsIds = 
new ArrayList<>(); 


@Transactional 

public void save(){ 
populateBookAuthor () ; 
bookDAO.save(product) ; 


private void populateBookAuthor() { 
selectedAuthorsIds.stream().map( (id) -> { 
return new Author (id); 
}).forEach(product :: add); 


O método populateBookAuthor usa um pouco da parte dos lambdas 
do Java 8. Lembre também de criar o método add na classe Book, para 
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que possamos adicionar cada um dos livros. Para que nossa tela funcione de 
maneira adequada, precisamos fornecer a lista de autores que deve ser exibida. 

Perceba que a tag select Items faz referência a propriedade authors, 
da classe AdminBooksBean 


<f:selectItems value="#{adminBooksBean.authors}" var="author" 
itemLabel="#{author.name}" itemValue="#{author.id}" /> 


Para que isso funcione, é necessário que pelo menos seja criado um getter 
no nosso bean. 


@Model 
public class AdminBooksBean { 


private List<Author> authors = new ArrayList<Author>() ; 


public List<Author> getAuthors() { 
return authors; 


Nesse momento, o nosso código nem compila, já que ainda não criamos 
a classe que representa o autor. Ainda bem que esse é um problema fácil de 
se resolver. 


package br.com.casadocodigo.loja.models; 


CEntity 
public class Author { 


@Id 

@GeneratedValue(strategy = GenerationType. IDENTITY) 
private Integer id; 

private String name; 
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/** 


* @deprected Apenas para o uso dos frameworks. 
*/ 
public Author Of 


public Author(Integer id) 1 
this.id = id; 


//métodos de acesso 


Quando você reiniciar o servidor, dada a nossa configuração do Hiber- 
nate, o banco de dados já vai ser atualizado com a nova tabela. Para facilitar, 
já vamos criar alguns autores, basta executar os seguintes inserts no seu banco 


de dados: 


insert into Author (name) values(º Alberto Souza’); 
insert into Author (name) values(’Mauricio Aniche’); 
insert into Author (name) values(' Adriano Almeida’); 
insert into Author (name) values(’Paulo Silveira’); 
insert into Author (name) values(’Sergio Lopes’); 
insert into Author (name) values(’Guilherme Silveira’); 


Agora, caso você acesse a tela de cadastro de novos livros, vai perceber que 
ela até funciona, mas não exibe nenhum autor no campo de seleção. Na ver- 
dade, o leitor mais atento talvez até tenha percebido isso, já que em nenhum 
momento foi carregada uma lista de autores em nosso código. 

Nesse momento, sempre que usarmos a classe AdminBooksBean vamos 
ter a necessidade de carregar a lista de autores. Pensando nisso, uma primeira 
solução que pode passar pela nossa cabeça é a de carregar essa lista direto no 
construtor. 


@Model 
public class AdminBooksBean { 
@Inject 
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private AuthorDAO authorDAO; 
private List<Author> authors = new ArrayList<Author>() ; 


public AdminBooksBean(){ 
this.authors = authorDAO.1list(); 


O grande problema aqui é que o construtor vai ser executado antes da in- 
jeção de dependências ter sido realizada no nosso objeto. Para resolver isso, 
pensando em Orientação a Objetos (OO), bastaria que recebêssemos as de- 
pendências pelo construtor. 


@Inject 

public AdminBooksBean(AuthorDAO authorDAO,BookDAO bookDAO) f{ 
this.bookDAO = bookDAO; 
this.authors = authorDAO . list (); 


Caso você tente fazer essa alteração, no momento do restart do servidor, 
você receberá a seguinte exception: 


WELD-001435: Normal scoped bean class 

br.com.casadocodigo. loja.managedbeans. AdminBooksBean is not 
proxyable because it has no no-args constructor - Managed Bean 
[class br.com.casadocodigo.loja.managedbeans.AdminBooksBean] with 
qualifiers [@Any @Default]. 


Aqui somos obrigados a aceitar o destino. A especificação do CDI define 
que toda classe cujo escopo for superior a dependent precisa ter um constru- 
tor sem argumentos. Podemos até trabalhar com um construtor sem argu- 
mentos e outro com, como ja estamos acostumados a fazer para atender os 
frameworks, mas nesse caso usaremos uma solução alternativa. 

Como precisamos rodar um código após a parte de injeção ter sido feita, 
podemos criar um método no nosso bean e anotá-lo com @PostConstruct. 
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@PostConstruct 
public void loadObjects(){ 
this.authors = authorDAQ.1list(); 


Essa annotation vem de uma especificação chamada Commons Anno- 
tations for the Java Plaftorm. Vocé pode saber um pouco mais sobre ela 
acessando o endereço https://jcp.org/en/jsr/detail?id=250. 

Seu objetivo é definir algumas annotations que podem ser úteis em todo 
tipo de aplicação Java, desde aplicações desktop até aplicações web que ro- 
dem dentro de servidores de aplicações, igual à nossa situação. Lembre-se de 
que esse método é chamado automaticamente pela nossa implementação do 
CDI, idealmente você nunca deveria chamá-lo manualmente. Até pensando 
nisso, a especificação permite que você diminua a visibilidade do método para 


private. 


Problemas com a conversão 


Com os autores devidamente carregados, chegou a hora de tentarmos re- 
alizar novos cadastros. O problema é que, na hora de concluir o cadastro, 
recebemos a seguinte exception: 


javax.servlet.ServletException: java.lang.ClassCastException: 
java.lang.String cannot be cast to java.lang. Integer 


O JSF não conseguiu converter os ids dos autores para o tipo inteiro es- 
perado dentro da lista. O problema é, até certo ponto, curioso, pois se adicio- 
narmos um System.out dentro do método que adiciona os autores dentro 
do livro, serão impressos todos os ids que foram selecionados. 


private void populateBookAuthor () { 
//Essa linha imprime => [3, 1, 2]===== 
System.out.println(selectedAuthorsIdst"=====") ; 
selectedAuthorsIds.stream().map( (id) -> { 
return new Author(id) ; 
}).forEach(product :: add); 
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A grande armadilha aqui é o uso da parte de Generics. Quando defi- 
nimos o tipo de uma lista, somos obrigados a respeita-lo, só que apenas em 
tempo de compilação. Em tempo de execução, até existem meios de recu- 
perar o tipo que foi definido e garantir que ele só entrará na lista de valores 
que respeitem a restrição. A seguir, veja um exemplo usando um pouco de 
reflection. 


Field field = AdminBooksBean.class.getDeclaredField 
("selectedAuthorsIds") ; 
ParameterizedType type = 
(ParameterizedType) field.getGenericType() ; 
//imprime java.lang.Integer 
System.out.println(type.getActualTypeArguments() [0]); 


Só que nesse ponto o JSF comete um pecado. A implementação pa- 
drão que usamos, a Mojarra, não faz essa verificação de maneira auto- 
mática e, por consequência, adiciona objetos do tipo String à lista que 
deveria ser de inteiros. E é exatamente essa falha, ou podemos chamar 
até de preguiça, que faz o nosso código receber uma exception do tipo 





java. lang.ClassCastException. 

Para contornar esse problema, pelo menos neste momento, temos de re- 
correr ao uso de um detalhe de implementação do JSF. Podemos configurar 
para ser usado um conversor específico para os valores de um determinado 
componente. 


<h:selectManyListbox 
value="#{adminBooksBean.selectedAuthorsIds}" 
converter="javax.faces.Integer"> 
<f:selectItems value="#{adminBooksBean.authors}" 
var="author" 
itemLabel="#{author.name}" itemValue="#{author.id}" /> 
</h: selectManyListbox> 


Repare que passamos o id do conversor responsável por transformar 
objetos do tipo String em objetos do tipo Integer. Essa informação pode 
ser encontrada dentro da própria classe que define o conversor. 


package javax.faces.convert; 
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public class IntegerConverter implements Converter { 


/** 
* <p>The standard converter id for this converter.</p> 
*/ 
public static final String CONVERTER_ID = 
"javax.faces.Integer"; 


Você também pode navegar até http://docs.oracle.com/javaee/7/tutorial/ 
jsf-page- coreoo1.htm para encontrar os ids necessários. 

Independente da forma, estamos quebrando o encapsulamento do con- 
versor para conseguir realizar uma simples transformação. Provavelmente, 
não acontecerá, mas, caso o id seja trocado, muitas aplicações podem sofrer. 

Pronto, agora conseguimos cadastrar novos livros com seus autores. No 
próximo capítulo, vamos melhorar ainda mais essa parte de conversão! 


4.2 LIMPANDO O FORMULÁRIO 


Depois que você realizou alguns cadastros, deve ter percebido que os dados 
ainda permaneceram nos campos do formulário. Essa é uma característica 
marcante do JSF. Por padrão, ele sempre mantém o estado da árvore de com- 
ponentes usadas. Em nosso caso, estamos usando inputs que são preenchidos 
com valores vindos dos beans, então os dados são mantidos mesmo após um 
request. 

Para o nosso cadastro, esse comportamento não faz muito sentido. Depois 
de cadastrar um novo livro, queremos que esse formulário fique limpo. Para 
fazer isso, precisamos limpar os dados mantidos dentro de todos os objetos 
que estão ligados ao nosso formulário. 


@Transactional 

public void save(){ 
populateBookAuthor () ; 
bookDAO. save(product) ; 
clearObjects(); 
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private void clearObjects() { 
this.product = new Book(); 
this.selectedAuthorsIds.clear(); 


Perceba que simplesmente instanciamos de novo os objetos. No caso da 
lista, retiramos todos os objetos que estavam dentro dela, mas poderiamos ter 
atribuido uma nova instancia do ArrayList. 


4.3 LISTANDO OS LIVROS 


Outra funcionalidade importante na parte de administração da Casa do Có- 
digo é a de listar os livros cadastrados. O interessante dessa implementação 
é que não precisaremos usar nada de novo, e servirá como revisão de alguns 
dos conceitos que foram discutidos até aqui. 

Mais uma vez, vamos começar pensando na página, que terá o nome de 
lista.xhtml, e ficará, como já era esperado, na pasta livros: 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets"> 
<h: body> 
<h:dataTable value="#{adminListBooksBean.books}" 
var="book"> 
<h: column> 
<f:facet name="header"> 
Titulo 
</f:facet> 
#{book.title} 
</h:column> 
<h: column> 
<f:facet name="header"> 
Número de paginas 
</f:facet> 
#{book.number0fPages} 
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</h:column> 
<h: colum> 
<f:facet name="header">Autores</f:facet> 
<ui:repeat var="author" 
value="#{book.authors}"> 
#{author.name}| 
</ui:repeat> 
</h:column> 
</h: dataTable> 
</h: body> 
</html> 


É uma página bem comum, apenas usamos algumas tags do JSF para cri- 
armos uma tabela e, além disso, exibimos quais são os autores associados ao 
livro. Para essa tela funcionar, perceba que precisamos de uma nova classe 
chamada AdminListBooksBean 


package br.com. casadocodigo. loja.managedbeans. admin; 


@Model 
public class AdminListBooksBean { 


@Inject 
private BookDAO bookDAO; 
private List<Book> books = new ArrayList<Book>() ; 


@PostConstruct 


private void loadObjects(){ 
this.books = bookDAO.list(); 


public List<Book> getBooks() { 
return books; 


Perceba que nao tem nada de muito diferente do que ja fizemos 
no bean responsavel pelo cadastro de novos livros. Também usamos o 
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@PostConstruct para acessar o DAO injetado, e invocarmos o método que 
vai retornar a lista de livros. Por sinal, esse método é justamente a única coisa 


nova nesse trecho de código. 


public class BookDAO 1 


@PersistenceContext 
private EntityManager manager; 


public void save(Book product) { 
manager . persist (product); 


public List<Book> list() { 
return manager.createQuery("select distinct(b) from 
Book b join fetch b.authors",Book.class) 
.getResultList (); 


A decisão de criar uma nova classe para usar nessa nova tela é uma decisão 
deste autor que vos escreve. Não existe nenhuma regra dizendo que você deve 
ter um bean para cada nova tela. Entretanto, a Orientação a Objetos (OO) 
diz que quanto mais separarmos as responsabilidades, melhor será quando 
tivermos que evoluir nosso código. Sem contar que, por qual motivo você 
ficaria carregando a lista de livros? Ela só é usada nessa tela, e não na outra. 


4.4 FORWARD X REDIRECT 


Agora que já inserimos e listamos, chegou a hora de melhorar um pouco o 
fluxo entre essas operações. Neste momento, quando um livro é inserido, o 
usuário volta para a mesma tela de cadastro. Nesse tipo de cenário, o fluxo 
mais indicado é voltar com o usuário para a listagem, talvez mostrando uma 


mensagem de sucesso. 


OTransactional 
public String save(){ 
populateBookAuthor() ; 
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. save (product) ; 
clearObjects(); 
return "/livros/lista"; 


Esse código implementa justamente o fluxo sugerido. Quando acabamos 
de salvar um novo livro, pedimos para o JSF nos direcionar para o endereço de 
listagem, responsável por listar os produtos. O ponto negativo dessa solução 
é que o endereço que fica na barra do navegador ainda é o último acessado 
pelo usuário, que, nesse caso, foi um post para /livros/form. Caso o 
nosso cliente aperte um F'5, o navegador vai tentar refazer a última operação, 
causando uma nova inserção de produto no sistema. 





e Cc localhost:8080 /casadocodigo/livros /form.xhtml 
x 
Titulo Número de páginas Confirm Form Resubmission 
Scala como programar 100 Alberto Soi 
Java pratico 200 Alberto Sol The page that you're looking for used information that you entered. 


Returning to that page might cause any action you took to be repeated. 








Java 8 250 Alberto Soi Do you want to continue? 

Play 200 Alberto Sot 

Livro sobre wildfly 100 Alberto Soi Cancel Continue 
Livro sobre tomcat 200 Alberto Soy 

Javascrupt 100 Alberto Souza Mauricio Amiche Adriano Almeidal 

livro sobre ios 200 Alberto Souzal Mauricio Anichel Adriano Almeidal 

livro sobre gelatto 100 Alberto Souzal Mauricio Anichel Adriano Almeidal 

lidando com legado 100 Alberto Souzal Mauricio Anichel Adriano Almeidal 

lidando com legado 100 Alberto Souzal Mauricio Anichel Adriano Almeidal 

Livro sobre ddd 100 Alberto Souzal Mauricio Anichel Adriano Almeidal Paulo Silveiral Sergio Lopes! 
Testando do inicio ao fim 200 Mauricio Anichel 

Photoshop 200 Mauricio Anichel Paulo Silveiral 

TDD 200 Mauricio Anichel 

Livro sobre ocaml 100 Mauricio Anichel Paulo Silveiral Sergio Lopes! 

infer 200 Mauricio Anichel 

infer 200 Mauricio Anichel 

SEO 100 Adriano Almeidal 

SEO 200 Adriano Almeidal 

Phyton como programar 150 Paulo Silveiral Sergio Lopes! 

Lua 100 Paulo Silveiral Sergio Lopes! 


Fig. 4.2: Problema do forward depois de um post 


Observe que o próprio navegador percebe que tem algo de estranho e 
pergunta se vocé tem certeza de que quer reenviar os dados. Essa técnica de 
redirecionamento que acontece apenas do lado do servidor é o que chama- 
mos, no mundo Java, de forward. O browser nem sabe o que aconteceu, tanto 
que, se olharmos no console do Chrome, ele só vai identificar um request. 
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O O Y View: = = Options Preserve log Disable cache 
XHR Script Style Images Media 
Name Method Status 
Patt Text 
| form.xhtmi 200 
POST 
[casadocodigo/livros OK 


hrrp://localhost:8080/casadocodigo/livros /form.xhtm! 


1 requests | 3.6 KB transferred | Finish: 89 ms | DOMContentLoaded: 239 ms | Load: 235 ms 


Fig. 4.3: Chrome tools indica apenas um request 


É considerado uma má prática realizar um forward após o usuário ter 
feito um post, justamente por conta do problema da atualização. Para esse 
cenário, a melhor solução é forçar o usuário a fazer uma nova requisição para 
a nossa listagem e, dessa forma, permitir que ele atualize a página sem que 
um novo post seja realizado. 


@Transactional 
public String save()f{ 
populateBookAuthor() ; 
. save (product) ; 
return "/livros/lista?faces-redirect=true"; 


O parâmetro faces-redirect=true indica para o JSF que, em vez de 
simplesmente fazer um forward, é necessário que ele retorne o status 302 para 
o navegador, solicitando que este faça um novo request para o novo endereço. 


O 9 Y View: = =~ Options Preserve log Disable cache 


XHR Script Style Images Media 


Name Method Status 

Path ext 
| form.xhtml 302 

= [casadocodigo/livros POST Found 
| list.xhtmi http://localhost:8080/casadocodigo/livros/form.xhtm! 200 





/casadocodigo/livros OK 


2 requests | 4.3 KB transferred | Finish: 65 ms | DOMContentLoaded: 200 ms | Load: 198 ms 


Fig. 4.4: Chrome tools indica dois requests 
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¥ General 
Remote Address: 127.0.0.1:a0R0 
Request URL: http://localhost:8080/casadocodigo/livros/form. xhtml 
Reguest Method: PosT 
Status Code: » 302 Found 
Y Response Headers view source 
Connection: keep-alive 
Content-Length: 0 
Date: Tue, 16 Jun 2015 16:07:56 GMT 
Location: http: //Localhost:B08B/casadocodigo/Livros/List. xhtml 
Server: WildFly/8 
Set-Cookie: csfcfcsNIVnNY¥cs3D; path=/casadocodigo; HttpOnly 
X-Powered-By: Undertow/i 


Fig. 4.5: Detalhes da resposta gerada pelo servidor 


Perceba que, entre os cabeçalhos contidos na resposta, existe um chamado 
Location, que informa justamente qual é o endereço ao qual o navegador 
deve fazer a próxima requisição. Essa técnica, em que fazemos um redirect do 
lado do cliente logo após um post válido, é um padrão conhecido na web, 
chamado de Always Redirect After Post, e deve ser sempre utilizado. 





ESTE PADRÃO NÃO É MUITO COMUM NO JSF 


Por mais que esse padrão seja muito conhecido na web, o JSF não 
nos força a utilizar essa boa prática por conta do seu estilo de manter es- 
tado dos componentes no servidor. Aqui, é apenas uma questão de gosto. 
Este autor não enxerga a vantagem em deixar de trabalhar com o modelo 
padrão. Prefiro deixar para usar essa manutenção do estado quando real- 
mente for necessário, por exemplo, quando estivermos trabalhando com 
validação. Além disso, acabamos de tirar um código que não tinha nada 
a ver com nossa lógica da aplicação, que era a limpeza dos objetos, apenas 
para não mantermos os dados no nosso formulário. 











4.5 EXIBINDO A MENSAGEM DE SUCESSO 


Ainda sobre o nosso redirect, geralmente é necessário que indiquemos para 
o usuário que tudo ocorreu bem. Isso é feito exibindo uma mensagem de 
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sucesso para o cliente em questão. 
Uma das maneiras de realizar essa tarefa é utilizando uma classe do JSF, 
de que você ainda vai ouvir falar bastante, chamada FacesContext. 


@Transactional 

public String save(){ 
populateBookAuthor() ; 
bookDAO. save (product) ; 


FacesContext facesContext = 

FacesContext. getCurrent Instance(); 
facesContext . addMessage (null, 

new FacesMessage ("Livro gravado com sucesso")); 


return "/livros/list?faces-redirect=true"; 


A classe FacesContext é usada internamente pelo JSF e contém várias 
informações associadas a um request na aplicação. A seguir, temos alguns 
métodos de exemplo: 


e getExternalContext () - para acessarmos objetos da especificação 
de Servlets; 


e getMessagesList () — para termos acesso a todas as mensagens adi- 
cionadas; 





e addMessage(...) -para adicionarmos uma mensagem a ser exibida 
na view; 


e isValidationFailed() - para verificar se houve falhas no processo 





de validação. 


Ainda existem vários outros métodos. Perceba que, inclusive, usamos o 
addMessage para adicionar a mensagem de sucesso. O segundo parâmetro é 
até bem claro, a classe FacesMessage é a abstração do JSF para representar 
uma mensagem que vai ser adicionada à tela. Já o primeiro parâmetro, que 
no nosso caso foi nul1, descobriremos o motivo em alguns minutos. 
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Adicionamos a mensagem, mas uma pergunta que fica é: onde e como 
vamos mostrar essa informação para o usuário? No nosso caso, queremos que 
ela seja exibida na tela de listagem dos livros, mas só quando realmente tiver 
mensagens. Vamos alterar o arquivo lista.xhtml, e incluir a tag do JSF 
responsável por isso. 


<h: body> 
<h:messages/> 
<h:dataTable value="#{adminListBooksBean.books}" var="book"> 


</h: body> 


A tag messages realiza todo o trabalho de pegar as mensagens adicio- 
nadas por meio do FacesContext e exibir na nossa tela. 

Só para não esquecermos, vamos comentar sobre o nul1 que está sendo 
passado como argumento no método addMessage. Esse primeiro para- 
metro serve para indicarmos o id do elemento com o qual a mensagem 
deve estar associada. Como não queremos ligar a mensagem a nenhum ele- 
mento, passamos o null e a deixamos global, podendo ser exibida pela tag 
messages. 

Agora, o engraçado é que, caso você realize um novo cadastro, a men- 
sagem ainda não vai ser exibida. Quando adicionamos mensagens com o 
método addMessage, elas ficam disponíveis durante a execução do request 
atual. Como estamos fazendo um redirect do lado do cliente, elas se perdem, 
já que, para exibir a listagem, é feita uma nova requisição. Não se preocupe, 
esse é um problema clássico em aplicações web, e todos os frameworks famo- 
sos já resolvem isso para nós. 


@Transactional 

public String save(){ 
populateBookAuthor () ; 
bookDAO. save(product) ; 


FacesContext facesContext = 


FacesContext.getCurrentInstance() ; 
facesContext.getExternalContext() .getFlash() 
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. setKeepMessages (true); 
facesContext . addMessage (null, 

new FacesMessage ("Livro gravado com sucesso")); 
return "/livros/list?faces-redirect=true"; 


O método getFlash retorna um objeto do tipo Flash. Invocando 





o setKeepMessages nesse objeto, estamos dizendo ao JSF que ele deve 
manter as mensagens até o próximo request. Pronto, com essa alteração, nossa 
mensagem de sucesso vai começar a ser exibida na tela da listagem. 





ESCOPO FLASH É UM AJUSTE FINO 


O jeito mais comum de passar informações em um request é por meio 
de parâmetros. Pensando do jeito mais normal possível, já que queremos 
passar a mensagem de sucesso para o request que vai retornar a tela de 
listagem, poderíamos ter o seguinte retorno no método save: 


return "/livros/list?faces-redirect=true 
&sucesso=Livro gravado com sucesso"; 


Poderíamos acessar o parâmetro sucesso a partir do nosso 
bean responsável pela tela de listagem, e adicionar a mensagem no 


FacesContext. 


HttpServletRequest request = (HttpServletRequest) 
FacesContext . getCurrentInstance() .getExternalContext () 
.getRequest () ;sx 

facesContext.addMessage(null, 
new FacesMessage (request. getParameter ("sucesso"))) 


Como isso daria muito mais trabalho, o escopo flash cai como uma 
luva, mantendo a mensagem até o próximo request! 











4.6 ISOLANDO O CÓDIGO DE INFRAESTRUTURA 


Vamos analisar com um pouco mais de cuidado o código que acabou sendo 
escrito no método save. 
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@Transactional 

public String save()f{ 
populateBookAuthor () ; 
bookDAO. save(product) ; 


FacesContext facesContext = 

FacesContext .getCurrentInstance(); 
facesContext. getExternalContext () .getFlash() 

. setKeepMessages (true); 
facesContext . addMessage (null ,new 

FacesMessage ("Livro gravado com sucesso")); 


return "/livros/list?faces-redirect=true"; 


Acabamos com mais linhas de código dedicadas a usar detalhes internos 
do JSF do que para resolver o nosso problema em si, que é o de gravar novos 
livros. Perceba que estamos escrevendo o código necessário para recuperar 
um FacesContext quando, na verdade, só estamos interessados em usá-lo. 
Aqui, de novo, temos uma motivação clara para usar o conceito de injeção de 
dependências: isolar a criação do objeto do seu uso. 


@Model 
public class AdminBooksBean { 


@Inject 
private FacesContext facesContext ; 


@Transactional 

public String save(){ 
populateBookAuthor () ; 
bookDAO. save (product); 


facesContext .getExternalContext () .getFlash() 

. setKeepMessages (true); 
facesContext .addMessage (null, 

new FacesMessage ("Livro gravado com sucesso")); 
return "/livros/list?faces-redirect=true"; 
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Perceba que pedimos para receber injetado o objeto do tipo 
FacesContext em vez de ficar criando todas as vezes em que preci- 
sarmos dele. Agora, quando tentamos subir a aplicação, recebemos a 
seguinte exception: 


WELD-001408: Unsatisfied dependencies for type FacesContext with 
qualifiers @Default at injection point [BackedAnnotatedField] 
@Inject private br.com.casadocodigo.loja.managedbeans. admin 

. AdminBooksBean. facesContext at 
br.com. casadocodigo. loja.managedbeans. admin. AdminBooksBean 

. facesContext (AdminBooksBean. java:0) 





Ela indica que o WELD não foi capaz de injetar o objeto no atributo 
facesContext da classe AdminBooksBean. A classe FacesContext é 
abstrata, portanto, não pode ser instanciada. Sua implementação padrão, a 
FacesContext Imp1, tem um construtor que recebe objetos específicos do 
JSF também. 


public FacesContextImpl(ExternalContext ec, 
Lifecycle lifecycle) { 


} 


Até a versão 2.2, versão atual do JSF, não tem uma integração completa 
com o CDI. Alguns componentes, como o FacesContext, ainda não são 
gerenciados pelo container de injeção. A parte legal é que isso não é um pro- 
blema muito grande para nós, basta que ensinemos ao CDI como ele deve 
criar um objeto do tipo FacesContext. 


package br.com.casadocodigo.loja.infra; 


import javax.enterprise.context.ApplicationScoped; 
import javax.enterprise.context .RequestScoped; 
import javax.enterprise.inject.Produces; 

import javax.faces.context.FacesContext ; 
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CApplicationScoped 
public class FacesContextProducer { 


@Produces 
@RequestScoped 
public FacesContext get(){ 
return FacesContext.getCurrentInstance(); 


O método anotado com @Produces deve ser sempre usado quando o 
processo de criação de um objeto não é o padrão. Outra situação é quando 
queremos produzir um objeto de uma classe que não é gerenciada pelo CDI. 
O FacesContext, por coincidência, se enquadra nas duas situações. Ainda 
usamos duas anotações referentes ao escopo: 


e GApplicationScoped- para dizer que só é necessária uma instância 


do FacesContextProducer; 


e GRequestScoped — para dizer que o método get deve ser chamado 


uma vez a cada novo request. 


É importante que o FacesContext seja novamente produzido a cada 
request, caso contrário, você pode acabar injetando uma instância que foi po- 
pulada com informações de outra requisição. 





JSF 2.3 MAIS INTEGRADO COM O CDI 


A nova versão do JSF virá bem mais integrada ao CDI. Componentes 
internos já vão ter produtores default, nos poupando de criar este código 
dentro do nosso projeto. 

Caso queira saber mais sobre as novas integrações, acesse http:// 
jdevelopment.nl/jsf-23/. 
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Isolando a adição de mensagens no Flash 


Nosso código melhorou um pouco, mas ainda temos 2 linhas que são res- 
ponsáveis por adicionar uma mensagem no flash. 


facesContext .getExternalContext () .getFlash() 
. setKeepMessages (true) ; 
facesContext .addMessage (null, 
new FacesMessage("Livro gravado com sucesso")); 


Este é um dos trechos de código que também geram dor de cabeça. Para 
o nosso caso, o addMessage só faz sentido se você chamar a linha de cima. 
A chance de isso ser esquecido é relativamente alta e, provavelmente, vamos 
acabar perdendo um tempo precioso para achar a causa do bug. 

Um outro fato que devemos considerar é que estamos programando ori- 
entando a objetos, e podemos criar abstrações um pouco melhores para que 
o código fique mais fácil de ser entendido. 


@Model 
public class AdminBooksBean { 


@Inject 
private MessagesHelper messagesHelper; 


@Transactional 

public String save(){ 
populateBookAuthor () ; 
bookDAO. save (product) ; 


messagesHelper.addFlash( 
new FacesMessage("Livro gravado com sucesso")); 
return "/livros/list?faces-redirect=true"; 


Perceba que agora temos um método que diz claramente o que está sendo 
feito. Usamos uma nova classe chamada de MessagesHelper, que foi criada 


justamente para isolar esse comportamento. 
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package br.com.casadocodigo.loja. infra; 


import javax.enterprise.context.ApplicationScoped; 
import javax.faces.application.FacesMessage; 
import javax.faces.context.FacesContext; 

import javax.inject.Inject; 


public class MessagesHelper { 


@Inject 
private FacesContext facesContext ; 


public void addFlash(FacesMessage facesMessage) { 
facesContext .getExternalContext() .getFlash() 
. setKeepMessages (true) ; 
facesContext .addMessage (null, facesMessage) ; 


4.7 CONCLUSÃO 


Neste capitulo, evoluimos nosso cadastro. Além disso, vimos um conceito 
importante em aplicações web, que é o escopo Flash e a capacidade de fa- 
zermos redirects no lado do cliente. Este último, apesar de ser um conceito 
natural em uma aplicação web, não é muito usado no mundo JSF, por conta 
do modelo de programação imposto pelo framework. 

Também começamos uma discussão sobre os mecanismos de conversão 
dos valores vindos dos requests para os tipos do nosso sistema e, infelizmente, 
caímos em uma situação ruim, causada pelo próprio JSF. 

Para fechar, discutimos um pouco de boas práticas de código, e vimos 
como o CDI nos ajudou a deixar o nosso código um pouco mais desacoplado 
e coeso. 

No próximo capítulo, vamos tentar melhorar a conversão da nossa lista de 
autores e também tratar sobre a validação dos valores vindos do formulário. 
Caso ainda esteja com fôlego, não pare agora e continue a leitura. 


81 


CAPITULO 5 


Validação e conversão de dados 


O nosso cadastro já está funcional, mas estamos deixando de fazer uma coisa 
básica: validar os dados de entrada. Neste momento, caso um usuário queira 
cadastrar um novo livro, ele tem a opção de deixar todos os campos em 


branco. 


5.1 VALIDAÇÃO BÁSICA 


A primeira opção de solução para essa situação é escrever o código de valida- 
ção dentro do próprio método save, da classe AdminBooksBean. 


@Transactional 
public String save(){ 
populateBookAuthor () ; 


if (product .getTitle()==null || 
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product .getTitle() .trimQ .isEmpty 0) 
messagesHelper. addMessage 
(new FacesMessage("titulo obrigatorio")); 


if (product .getDescription()==null || 
product .getDescription().trim() .isEmpty()){ 
messagesHelper. 
addMessage 
(new FacesMessage("descrigéo obrigatoria")); 


if (messagesHelper.hasMessages()){ 
//volta para a mesma tela 
return "/livros/form"; 


bookDAO. save (product); 
messagesHelper.addFlash 
(new FacesMessage("Livro gravado com sucesso")); 
clearObjects(); 
return "/livros/list?faces-redirect=true"; 


Apesar de adicionarmos uns ifs e simularmos uns novos métodos na 
classe MessageHelper, a lógica não tem nada de complicado, na verdade, 
deve ser bem parecida com várias das quais o leitor já presenciou. Um ponto 
negativo dessa solução é que o Managed Bean, que idealmente deveria apenas 
ficar chamando lógicas do sistema e controlando qual é o próximo passo de 
navegação, agora também está responsável pelo código de validação. 

Como uma das ideias originais do JSF é ser muito útil para aplicações com 
muitos formulários, suas tags de input já vêm com atributos que habilitam 
esse tipo de validação básica. 


<h:body> 
<h:messages/> 
<h:form> 
<div> 
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<h: outputLabel>Titulo</h: outputLabel> 
<h: inputText 
value="#{adminBooksBean. product.title}" 
required="true"/> 
</div> 
<div> 
<h: outputLabel>Descrig&o</h: outputLabel> 
<h: inputTextarea cols="20" rows="10" 
value="#{adminBooksBean. product .description)" 
required="true"/> 
</div> 
<div> 
<h:outputLabel>Número de paginas</h: outputLabel> 
<h: inputText 
value="#{adminBooksBean. product .number0fPages}" 
required="true"> 
<f:validateLongRange minimum="80"/> 
</h: inputText> 
required="true"/> 
</div> 
<div> 
<h: outputLabel>Prego</h: outputLabel> 
<h:inputText value="#{adminBooksBean.product.price}" 
required="true"> 
<f: validateDoubleRange 
minimum="10" maximum="100"/> 
</h: inputText> 
</div> 
<div> 
<h: outputLabel>Autores</h: outputLabel> 
<h: selectManyListbox 
value="#{adminBooksBean.selectedAuthorsIds}" 
required="true"> 
<f:selectItems 
value="#{authorsList.get()}" var="author" 
itemLabel="#{author.name}" 
itemValue="#{author.id}" /> 


</h:selectManyListbox> 
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</div> 
<h: commandButton value="Gravar" 
action="#{adminBooksBean.save}" /> 
</h:form> 
</h: body> 
</html> 


O atributo required é útil apenas para verificar se o campo foi preen- 
chido ou não. Além desse atributo, ainda podemos associar validadores mais 
específicos com os inputs. Por exemplo, usamos o validateDoubleRange 
para colocar um limite nos possíveis valores do livro. É importante ressaltar 
que essa validação é realizada do lado do servidor, pois as tags de validação 
do JSF não geram qualquer código JavaScript. 

Para exibir as mensagens de erro, também não precisamos alterar nada, 
dado que usamos a mesma tag messages. Para cada problema encontrado, o 
JSF adiciona mensagens exatamente do jeito que nós fizemos durante a lógica 
de criação de um livro. 

Com essas alterações, sem nem precisarmos alterar código Java, já conse- 
guimos nos precaver de formulários preenchidos de maneira incorreta. 

O leitor mais atento deve ter percebido que acontece uma falha de valida- 
ção: o usuário é automaticamente levado para a mesma tela em que ele estava, 
que é justamente o comportamento que nós desejamos. Além disso, também 
não foi necessário nenhum código extra para manter os valores dos inputs, 
situação muito comum em outros frameworks MVC. Esse é um ponto que 
devemos agradecer ao modelo manutenção de estado dos componentes do 
JSF, também conhecido como stateful. 


Um pouco sobre o ciclo de vida 


Quando realizamos a requisição, o JSF atualiza a árvore de componentes 
relativa à tela atual, aplicando os valores que foram preenchidos no formulá- 
rio. Veja a seguir um trecho de código da classe responsável por isso. 


/ x 
* ApplyRequestValuesPhase executes <code>processDecodes</code> 
* on each component in the tree so that it may update it’s 
* current value from the information included in the current 
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* request (parameters, headers, cookies and so on.) 
*/ 
public class ApplyRequestValuesPhase extends Phase { 
public void execute(FacesContext facesContext) 
throws FacesException { 


if (LOGGER.isLoggable(Level.FINE)) { 
LOGGER.fine("Entering ApplyRequestValuesPhase") ; 


} 

UIComponent component = facesContext.getViewRoot (); 
assert (null != component) ; 

try É 


component. processDecodes (facesContext) ; 


O comentário está em inglês, mas ele basicamente fala a mesma coisa do 
parágrafo anterior. Depois que os valores são associados aos componentes, 
ele vai aplicar as regras de validações e, aí, quando elas falham, basta ele rees- 
crever o HTML baseado no estado de cada elemento da tela. 

Quando trabalhamos no modo convencional, geralmente nós temos de 
tomar conta de uma parte desse fluxo. Por isso que, na opinião deste autor, o 
modelo híbrido geralmente é o melhor. Mantemos o estado quando necessá- 
rio, e recriamos tudo do zero quando for mais interessante, como no capítulo 
4 (seção 4.4) com o redirect. 


5.2 EXIBINDO AS MENSAGENS DE ERRO DE MANEIRA 
AMIGÁVEL 


Por mais que o formulário esteja sendo validado, as mensagens de erro ainda 
não dizem muita coisa sobre o problema em questão. 
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j_idt4:j_idt8: Validation Error: Value is required. 

j_idt4:j_idt1i2: Validation Error: Value is required. 

j_idt4:j_idti6: Validation Error: Value is less than allowable 
minimum of ?100º 

j_idt4:preco: Validation Error: Value is required. 

j_idt4:j_idt26: Validation Error: Value is required. 

j_idt4:j_idt28: Validation Error: Value is required. 


Pensando no cliente, essas mensagens e nada dizem praticamente a 
mesma coisa. Perceba que, antes de cada mensagem de validação, aparece 
uma espécie de id. Como não informamos nenhum id específico para nos- 
sos elementos, o JSF gera os dele para controle interno. Então, uma primeira 
ação para melhorar a mensagem é a de colocar ids para nossos elementos. 


<h:form> 
<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h:inputText value="#{adminBooksBean.product.title}" 
required="true" id="titulo"/> 
</div> 


Agora, se tentarmos cadastrar um livro sem titulo, a mensagem de vali- 


dação será parecida com a seguinte: 


j_idt4:titulo: Validation Error: Value is required. 


Perceba que ainda sobrou um identificador gerado pelo JSF. Eleéo ia do 
formulário ao qual o input pertence. Podemos usar o atributo prependId, 
da tag form, para dizer que não queremos que ele fique sendo adicionado 
como parte da identificação do elemento. 


<h:form prependId="false"> 
<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h:inputText value="#{adminBooksBean.product.title}" 
required="true" id="titulo"/> 
</div> 
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</h:form> 
Agora, quando ocorrer uma falha de validação, a mensagem será parecida 
com essa: 


titulo: Validation Error: Value is required. 


Esta alteração já deixa o nosso usuário um pouco mais feliz, entretanto, 
essa mensagem em inglês ainda não tem muito a ver com o nosso projeto. Para 
tentar melhorar, podemos recorrer a outro atributo das tags de formulário. 


<h: inputText value="#{adminBooksBean.product.title}" 
required="true" 
id="titulo" 
requiredMessage="Campo obrigatério"/> 





O atributo requiredMessage permite que você especifique uma men- 
sagem de validação relacionada ao atributo required. Com essa última 
alteração, quando tentamos cadastrar um livro sem dizer qual o título, rece- 
bemos a seguinte a mensagem de validação: 


Campo obrigatório 
Campo obrigatório 
Campo obrigatório 


Até que a mensagem ficou do jeito que nós queríamos, porém, perdemos 
o detalhe que informava qual campo tinha dado problema. Para resolver este 
problema, podemos recorrer à tag message. 


<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h:inputText value="#{adminBooksBean. product .title}" 
required="true" id="titulo" 
requiredMessage="Campo obrigatorio"/> 
<h:message for="titulo"/> 
</div> 
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Ela permite que associemos a mensagem com algum input da nossa pa- 
gina. Dessa forma, conseguimos exibir a mensagem onde for mais pertinente 
para a aplicação. 


5.3 TROCANDO AS MENSAGENS DEFAULT DO JSF 


Até que chegamos a uma solução de validação justa, só tem um detalhe que 
ainda pode nos incomodar, especificamente relacionado com a mensagem 
de validação. Decidimos que, quando o campo é obrigatório, vamos usar o 
texto de alerta “Campo obrigatório”. Caso você só tenha um formulário na 
aplicação, até que não faz diferença, mas em um contexto um pouco mais 
amplo, essa mensagem ficará espalhada em todos os lugares. 

Todas as mensagens de conversão e validação que são exibidas pelo 
JSF podem ser customizadas. Elas, por default, encontram-se no arquivo 
Messages.properties, que vem dentro do jar da especificação do JSF. 





TODAS AS MENSAGENS DE CONVERSÃO 


Caso fique curioso para saber todas as possibilidades, acesse http:// 
bit.ly/messages- properties-jsf. 











Para alterar essas mensagens, precisamos criar a nossa versão do arquivo 
e substituir as chaves que têm relação com a nossa aplicação. Para começar, 
vamos criar um arquivo chamado jsf messages.properties dentro de 


src/main/resources, com o seguinte conteúdo: 


javax.faces.component .UI Input .REQUIRED={0}: Campo obrigatório 


Usamos a mesma chave definida pelo JSF, só alteramos o valor. O parâme- 
tro de indice zero é justamente o id do elemento. Agora, precisamos ensinar 
ao JSF que ele sempre deve procurar as mensagens primeiro no nosso arquivo 
e, depois, no dele. Para isso, vamos alterar o arquivo faces-config.xml, 





que estáem src/main/webapp/WEB-INF. 


<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<faces-config xmlns="http://xmlns. jcp.org/xml/ns/javaee" 
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xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
version="2.2" 

xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 

http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig 2_2.xsd"> 


<application> 
<message-bundle>jsf_messages</message-bundle> 
</application> 
</faces-config> 


Vocé poderia ter colocado o arquivo em qualquer lugar no seu 





classpath, basta que informe na tag message-bundle. Com essa alte- 
ração, podemos inclusive apagar o uso do atributo requiredMessage dos 





nossos inputs. Agora, caso você tenha mantido a tag messages no início 
do seu formulário, quando acontecer um erro de validação, a mensagem será 
exibida do jeito que gostaríamos. 


titulo: Campo obrigatório 


Alterando a mensagem de conversão 


Voltando um pouco para os problemas de validação, um outro erro que 
pode existir no formulário de cadastro é a entrada de um valor não condizente 
com o tipo do campo. Por exemplo, um usuário pode digitar “dez” em vez de 
“10” no campo de número de páginas. 

Esse tipo de situação também acontece, em geral, com campos de valores 
de ponto flutuante, como é o caso do preço do nosso livro. Caso a pessoa digite 
“59,90, ocorrerá um problema de conversão para nosso tipo BigDecimal, 
já que a representação de um valor deste tipo deve ser feita com . (ponto), e 
não com , (vírgula). Será exibida a seguinte mensagem, também através da 


tag messages: 


preco: 59,90” must be a signed decimal number. 


Como podemos ver, é uma mensagem nada amigável para o usuário co- 
mum. 


Para exibir mensagens amigáveis e relativas aos erros de conversão, adi- 


cionamos as chaves que começam com avax. faces.converter. 
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javax.faces.converter.IntegerConverter.INTEGER=’’{2}’’ deve ser 
um número javax.faces.converter.BigDecimalConverter .DECIMAL={2} 
deve ser um valor separado apenas por "." 
Ex: 450.50 ou 4100.50 


javax.faces.component .UIInput .REQUIRED={0}: Campo obrigatório 


Quando algum problema de conversão acontece, o indice {2} recebe o 
id do input que originou o erro. 


5.4 INTEGRAÇÃO COM A BEAN VALIDATION 


A nossa validação já funciona integralmente, mas ainda tem um ponto que, 
pelo menos para este autor, é um pouco ruim. As nossas regras de validação 
estão na nossa view. Quem olha para nosso modelo não faz ideia do que é 
obrigatório para criar um livro. Sem contar que, caso tenhamos uma forma 
alternativa de cadastrar um livro — por exemplo, por meio de uma importação 
de um arquivo de texto -, não vamos conseguir reaproveitar as regras. 

Esse tipo de situação é tão comum que virou até especificação, a Bean 
Validation. E como não podia ser diferente, o JSF é completamente integrado 
com ela. Essa é uma das vantagens de se construir um projeto baseado no 
Java EE, uma vez que cada vez mais as especificações se integram de maneira 
transparente. 

A implementação que vamos utilizar é a que já vem por padrão no Wildfly, 
feita pelo time do Hibernate, chamada de Hibernate Validator. 

Só precisamos ensinar a Bean Validation o que deve ser validado na nossa 
classe Book. 


CEntity 
public class Book { 


@Id 
@GeneratedValue(strategy = GenerationType. IDENTITY) 


private Integer id; 


@NotBlank 
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@NotNull 
private String title; 


@NotBlank 

@NotNull 

@Length(min = 10) 

private String description; 


@Min (50) 
private int number0fPages; 


@DecimalMin("20") 
private BigDecimal price; 


@ManyToMany 

@Size(min = 1) 

ONotNull 

private List<Author> authors = new ArrayList<>(); 


A seguir, veja as explicações para algumas das annotations: 


e NotBlank - verifica se a string é diferente de null e se também não 


é vazia; 


* Length - verifica se o tamanho da string está entre um mínimo e um 


máximo; 
e Min — verifica se o número está entre o mínimo e o máximo; 


e DecimalMin - verifica se o ponto flutuante está entre o mínimo e o 


máximo; 


e Size — mesmo comportamento do @Length, mas pode ser aplicado 
para listas, arrays etc. 


É importante ressaltar que as validações são bem coesas. Por exemplo, 





a annotation @NotEmpty apenas dispara a validação de string vazia. A an- 
notation @NotNull só verifica se o valor for diferente de null. Por conta 
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disso, usamos a NotBlank, que é uma annotation específica do Hibernate 
Validator que une os dois comportamentos. 

Nesse exato momento, estamos com dois mecanismos de validação: o pa- 
drão da JSF e o da Bean Validation. Pensando na aplicação em si, não tem 
nenhum problema. Estamos protegidos por todos os lados. Entretanto, não é 
esse o jeito que você encontra no mercado. Hoje em dia, a Bean Validation é 
o jeito padrão de validar objetos no mundo Java, então vamos continuar com 
ela a partir daqui. 

A primeira coisa que você deve fazer é apagar o atributo required das 
tags, e também retirar qualquer tag de validação que você tenha adicionado 
nos inputs do formulário. Com essas alterações, quando tentamos realizar 
um novo cadastro com dados inválidos, recebemos as seguintes mensagens 
de erro: 


may not be empty 

length must be between 10 and 2147483647 
may not be empty 

must be greater than or equal to 50 

may not be null 

size must be between 1 and 2147483647 


Aqui temos dois problemas: a tag messages voltou a exibir as mensagens 
de erro, sem associar com o devido campo; e as mensagens são as default, 
definidas pelo próprio Hibernate Validator. 

Para resolver o primeiro, vamos voltar ao arquivo de mensagens default 
do JSF. 


javax.faces.validator.BeanValidator .MESSAGE={0} 


Na chave que define a mensagem associada aos erros de validação da Bean 
Validation, foi configurado para só exibir o erro, sem informar qual é o campo. 
Esse caso é ideal se você optar por mensagens associadas diretamente ao in- 
put. 


<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h:inputText value="#{adminBooksBean.product.title}" 
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id="titulo"/> 
<h:message for="titulo"/> 
</div> 


Agora, caso queiramos exibir todas as mensagens juntas, já acaba ficando 
confuso. A decisão vai depender do estilo do sistema. Para o nosso, vamos 
optar por exibir todas juntas. Para isso funcionar, vamos sobrescrever a chave 
do arquivo de mensagens do JSF e adicionar o nome do campo que falhou na 
validação. 


javax.faces.validator.BeanValidator.MESSAGE=(1):10) 


Com essa alteração, toda vez que a validação de um campo falhar, será 


exibida a mensagem com o seguinte padrão: 


idDoElemento:mensagem de validação 


Alterando as mensagens da Bean Validation 


Para fechar, só falta customizarmos as mensagens de validação. Elas 
ainda, por default, estão aparecendo em inglês, mas como a Casa do Código é 
uma empresa brasileira, devemos exibi-las em português. Para fazermos isso, 
assim como já fizemos com as mensagens padrões do JSF, teremos de alte- 
rar o valor de algumas chaves já definidas pela especificação e pelo Hibernate 
Validator. O arquivo com essas chaves já vem dentro do jar do próprio Hi- 
bernate Validator, e seu nome é ValiadtionMessages.properties. Na 
sequência, veja algumas chaves que já vêm por default: 


javax.validation.constraints.AssertFalse.message = 
must be false 

javax.validation.constraints.AssertTrue.message = 
must be true 

javax.validation.constraints.Past.message = 
must be in the past 

javax.validation.constraints.Pattern.message = 
must match "{regexp}" 

javax.validation. constraints .Size.message = 
size must be between {min} and {max} 
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org. hibernate.validator.constraints.NotBlank.message 
may not be empty 


org. hibernate.validator.constraints.NotEmpty.message 
may not be empty 


Para forçarmos as nossas mensagens, devemos criar um ar- 
quivo de mesmo nome na raiz do nosso classpath, no caso, em 
src/main/resources. Aqui, é importante lembrar para o leitor que o 
nome desse arquivo está na especificação da Bean Validation, não temos a 
opção de querer trocar de nome. Com o arquivo criado, basta redefinir as 
mensagens. 


org.hibernate.validator.constraints.NotEmpty.message 
não pode ser em branco 


org.hibernate.validator.constraints.NotBlank.message 
não pode ser em branco 


Pronto, combinando um pouco de especialização do JSF com um pouco 
de especialização da Bean Validation, conseguimos chegar ao resultado que 
queríamos. E ainda podemos escolher a melhor forma de exibir nossas men- 
sagens. 





VEJA TODAS AS MENSAGENS QUE PODEM SER ALTERADAS 


Para ver as chaves que podem ser sobrescritas sem a necessidade de 
ficar abrindo o jar, acesse https://github.com/hibernate/ 











hibernate/validator/ValidationMessages.properties 
5.5 CONVERTENDO A DATA 


Na Casa do Código, muitos livros são escritos o tempo todo. Para ter um fluxo 
interessante de lançamentos, foi decidido que os livros cadastrados devem ter 
uma data de lançamento. 


CEntity 
public class Book { 
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@NotNull 
@Future 
private Calendar releaseDate; 


Perceba que já estamos usando as annotations de validação da Bean Va- 
lidation. Usamos a @Future para garantir que as datas de lançamento são 
sempre do dia atual para a frente. Agora, precisamos colocar um campo novo 
no nosso formulário. 


<div> 
<h: outputLabel> 
Data de lançamento 
</h: outputLabel> 
<h: inputText 
value="#{adminBooksBean.product.releaseDate}" /> 
</div> 


Nosso código usa um simples input de texto para receber uma data. É 
sempre educado facilitar a vida do usuário, e o HTML 5 já traz um input que 
automaticamente abre um calendário. Para o usarmos, devemos setar o atri- 
buto type com o valor date. 


<h: inputText value="#{adminBooksBean.product.releaseDate}" 
type="date"/> 


O problema é que o JSF ignora este nosso atributo, ja que ele não faz parte 
dos atributos especificados para essa tag. Esse, na verdade, era um problema 
citado por vários usuários do framework; ele nos impedia de ter um controle 
mais fino sobre o HTML gerado. Só que, desde a última versão, o JSF vem ten- 
tando atacar este tópico ao fornecer mais controle aos elementos da view. Por 
exemplo, para este caso, podemos usar um novo namespace, que permite 
forçarmos o uso das propriedades que bem entendermos. 
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<html xmlns:h="http://java.sun.com/jsf/html" 
xmlns:f="http://xmlns.jcp.org/jsf/core" 
xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:pt="http://xmlns.jcp.org/jsf/passthrough"> 


<h: inputText 
value="#{adminBooksBean.product.releaseDate}" 
pt:type="date"/> 
</html> 


Esse é o objetivo do namespace _http://xmlns.jcp.org/jsf/passthrough. Per- 
ceba que, para trocarmos o type do input, usamos pt :type. Os atributos 
associados a esse namespace são ignorados pela fase de renderização do JSF 
e, dessa forma, ele será mostrado na página final. 

Agora, quando tentamos cadastrar um novo livro informando a data de 
lançamento, recebemos a seguinte mensagem de conversão: 


Conversion Error setting value ’2015-06-10’ for ’null Converter’. 


Caimos em um ponto especifico do JSE Como queremos que ele converta 
o valor inserido para um objeto que represente uma data, precisamos indicar 
que queremos usar um conversor específico. Perceba que o formato da data 
foi yyyy-MM-dd. Este é o formato usado pelo input do tipo date do HTML 
5. 

Essa padronização é interessante, já que ajuda no tratamento das datas 
do lado do servidor. Assim, sabemos que sempre vamos receber a data nesse 
formato. 


<div> 
<h:outputLabel>Data de lançamento</h:outputLabel> 
<h: inputText 
value="#{adminBooksBean.product.releaseDate}"> 
<f:convertDateTime pattern="yyyy-MM-dd"/> 
</h: inputText> 
</div> 
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Usamos a tag convertDateTime para associar o conversor com o input 
em questão. Agora, quando tentamos cadastrar, caímos em outro problema. 


javax.servlet.ServletException: 
java. lang. IllegalArgumentException: Cannot convert 6/10/15 
9:00 PM of type class java.util.Date to class java.util.Calendar 


A exception nos diz que não foi possível converter o tipo Date para 
Calendar, que é justamente o tipo do nosso atributo. O conversor asso- 
ciado pega o valor passado no request, e gera um objeto do tipo Date. E esse 
é justamente o nosso problema. 

Aqui, de novo vemos um pouco de preguiça na equipe da especificação, 
já que Calendar é um tipo bem antigo no Java e já merecia ter a conversão 
automática. 


Criando um Converter específico 


Para resolver este problema, vamos ser obrigados a criar a nossa imple- 
mentação de Converter. O que não é nenhum problema, já que o JSF já 
vem preparado para ser estendido nessa parte. 


package br.com.casadocodigo.loja.converters; 


import java.util.Calendar; 
import java.util.Date; 


import javax.faces.component .UIComponent ; 
import javax.faces.context.FacesContext; 
import javax.faces.convert.Converter; 

import javax.faces.convert.DateTimeConverter; 
import javax.faces.convert.FacesConverter ; 


@FacesConverter (forClass=Calendar.class) 
public class CalendarHtml5Converter implements Converter{ 


private static DateTimeConverter originalConverter = 
new DateTimeConverter () ; 


static À 
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originalConverter.setPattern("yyyy-MM-dd") ; 


@Override 
public Object getAsObject(FacesContext context, 
UIComponent component, 
String value) { 

Date date = (Date) 
originalConverter.getAsObject (context, 
component, value) ; 

if(date == null) { 
return null; 


Calendar newCalendar = Calendar.getInstance() ; 
newCalendar.setTime(date) ; 
return newCalendar; 


@Override 
public String getAsString(FacesContext context, 
UIComponent component, 
Object value) { 
if(value == null){ 
return null; 


Calendar calendar = (Calendar) value; 
return originalConverter.getAsString(context, component, 
calendar.getTime()); 


A grande jogada aqui é a annotation FacesConverter. Ela é a única 
configuração necessária para termos um novo conversor no sistema. Como 
já sabemos para qual tipo queremos converter, ainda usamos o atributo 
forClass. Dessa forma, o JSF já sabe que, sempre que associarmos um input 
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a uma propriedade do tipo Calendar, ele deve usar nosso conversor. 


Para não implementar todo o código da conversão, tiramos proveito da 





classe que já existe no framework, a DateTimeConverter. 

As implementações da interface Converter têm um papel muito im- 
portante no JSF. Elas são usadas tanto para transformar os valores vindos do 
request para objetos do nosso modelo quanto para transformar os nossos ob- 
jetos em Strings que devem ser associadas com os inputs exibidos na view. 


Perceba que foi necessário implementar dois métodos: 


e getAsOb ject - invocado para transformar o valor passado como pa- 
râmetro no tipo esperado pelo modelo; 


e getAsString - invocado para transformar o valor do modelo na 
String que deve ser associada ao input da view. 


5.6 CONVERTER PARA ENTIDADES 


Apesar de já termos adicionado nossas validações e tratado da conversão da 
data, ainda tem um ponto que incomoda este autor. 


<div> 
<h: selectManyListbox 

value="#{adminBooksBean.selectedAuthorsIds}" 

converter="javax.faces.Integer"> 

<f:selectItems value="#{adminBooksBean.authors}" 
var="author" 
itemLabel="#{author .name}" 

itemValue="#{author.id}" /> 


</h:selectManyListbox> 
</div> 


Associamos os autores a uma lista de inteiros para, só depois, realmente 
criar nossa lista de objetos do tipo Author e associar ao livro em questão. A 
seguir, segue o código para lembrá-los: 


private void populateBookAuthor () { 
selectedAuthorsIds.stream() .map( (id) -> { 
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return new Author (id)); 
}).forEach(product :: add); 


Adicionamos uma complexidade no nosso Managed Bean só porque o JSF 
não quis fazer um Converter mais inteligente. Agora chegou o momento 
de resolvermos isso e ficarmos mais felizes! 


Para termos uma ideia do que queremos, vamos começar alterando a 
nossa página. 


<div> 
<h: outputLabel>Autores</h: outputLabel> 
<h: selectManyListbox 
value="#{adminBooksBean. product. authors}"> 
<f:selectItems value="#{adminBooksBean.authors}" 
var="author" 
itemLabel="#{author.name}" itemValue="#{author}" /> 
</h:selectManyListbox> 
</div> 


A ideia é que sejamos capazes de adicionar os autores selecionados direta- 
mente no objeto do tipo Book que mantemos na classe AdminBooksBean. 
Para refletir essa alteração, vamos também alterar o Managed Bean, de modo 
que não é mais necessário ficar criando os objetos do tipo Author na mão. 


@Model 
public class AdminBooksBean { 


@Transactional 
public String save(){ 
productDAO. save (product); 


messagesHelper.addFlash( 
new FacesMessage("Livro gravado com sucesso")); 


return "/livros/list?faces-redirect=true"; 
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Bem mais direto! Agora, quando tentamos rodar, recebemos a seguinte 
exception: 


Caused by: java. lang.IllegalArgumentException: 
Can not set java.lang. Integer field 
br.com.casadocodigo.loja.models. Author.id to java.lang. Integer 


A exception é nova, mas o motivo é o mesmo que nos levou a usar uma 
lista de inteiros em vez de trabalhar com a lista de autores. Por conta de de- 
talhes do generics, nossa lista de autores do objeto do tipo Book acabou 
preenchida com um monte de inteiros. 

Caso você olhe toda a stack, verá que a exception, na verdade, é gerada 
quando o Hibernate vai persistir a lista e que não tem nada a ver com o JSF, 
pelo menos diretamente. Para tentar contornar essa situação, vamos criar 
nosso Converter genérico para converter entidades da JPA. 


package br.com.casadocodigo.loja.converters; 


import org.picketbox.util.StringUtil; 


@FacesConverter 
public class EntityConverter implements Converter { 


@Override 
public Object getAsObject (FacesContext context, 
UIComponent component, String value) { 


if (StringUtil.isNullOrEmpty(value)) 1 


return null; 


UISelectItems uiComponent = (UISelectItems) 
component. getChildren() 
.get(0); 
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Collection<?> objects = (Collection<?>) 
uiComponent.getValue() ; 


Object foundEntity = objects.stream() 
.filter((entity) -> { 
return getAsString(context, uiComponent, 
entity) .equals(value) ; 
}) .findFirst O .get O; 


return foundEntity; 


@Override 

public String getAsString(FacesContext context, 
UIComponent component, Object value) { 
Field idField = findIdField(value) ; 
return getIdValue(value, idField); 


private String getIdValue(Object value, Field idField) { 
try A 
Field field = value.getClass() 
. getDeclaredField(idField.getName()) ; 
field.setAccessible(true) ; 
return field.get (value) 
. toString () ; 
} catch 
(IllegalArgumentException | IllegalAccessException 
| NoSuchFieldException | SecurityException e) { 
throw new RuntimeException(e); 


private Field findIdField(Object value) 1 
Field idField = 
Arrays.stream(value.getClass() .getDeclaredFields()) 
.filter((field) -> field.getAnnotation(Id.class) 
!= null) 
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.findFirst() .get(); 
return idField; 


Respire fundo, esse não é um código tão simples. Vou pedir para não 
olhar muito para os métodos privados, eles usam um pouco de reflection 
e estão aí apenas para dar um apoio. Vamos começar pelo mais simples, que 
é relembrando o objetivo. 

Escrevemos esse Converter para que possamos adicionar diretamente 
os objetos selecionados no combo dentro da respectiva propriedade, que 
nesse caso éa List<Author> da classe Book. Como queremos fazer um 
conversor que possa ser aplicado para qualquer entidade, já implementamos 
um genérico. 

Agora, vamos começar a entender um pouco mais do código. Começare- 
mos pelo método mais direto, que é o getAsString. Como já estudamos 
(seção 5.5), ele é responsável por pegar um objeto e gerar a sua representação 
em String, para que o valor possa ser associado a um input da view. No nosso 
caso, queremos pegar qualquer entidade gerenciada pela JPA, acessar o atri- 
buto anotado com GId e recuperar seu valor. Por isso, tivemos de usar um 
pouco da API de reflection. 

O código foi quebrado em dois métodos privados justamente para que 
você pudesse olhar um pouco mais e, quem sabe, matar um pouco da curi- 
osidade. A reflection em si não é tão importante, por isso não vamos gastar 
tempo explicando linha por linha. 

O método getAsOb ject já requer um pouco mais de cuidado, pois ele 
tira proveito do estilo stateful do JSF. Vamos prestar atenção nas linhas 
de código que estão logo a seguir: 


@Override 
public Object getAsObject(FacesContext context, 
UIComponent component, String value) { 


UISelectItems uiComponent = (UISelectItems) 
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component .getChildren() .get (0); 


Collection<?> objects = (Collection<?>) 
uiComponent .getValue() ; 


O parâmetro do tipo UIComponent indica qual foi o elemento da árvore 
de componentes utilizado. Na página, usamos a tag selectManyListBox, 
que é representada pela classe HtmlSelectManyListbox. Com essa 
informação em mente, também já sabemos que o filho direto desse ele- 
mento é a tag select Items, que pode ser referenciada por meio da classe 
UISelectItems. É por isso que fazemos o cast do primeiro elemento re- 
tornado pelo método getChildren. Uma implementação mais precavida 
buscaria na lista retornada por um objeto do tipo UISelect Items. 

O objeto do tipo UISelectItems possui o método chamado 
getValue, que retorna para nós a lista associada ao elemento. Esse código 
só é possível de ser executado porque, a cada novo post para o sistema, o 
JSF remonta a árvore de componentes necessária, para aplicar os valores dos 
parâmetros, nos possibilitando acessar o seu estado. 

Agora, vem a segunda parte do código. Nela, o JSF vai invocar este mé- 
todo para cada id selecionado no combo. Pensando nisso, é necessário des- 
cobrir exatamente quais objetos da lista possuem os ids que foram escolhidos 
na hora do cadastro. 


Object foundEntity = objects.stream() .filter((entity) -> { 
return getAsString(context, uiComponent, 
entity) .equals (value); 
}) .findFirst O .getO; 


O parâmetro value representa o valor selecionado na tela. A nossa ló- 
gica simplesmente varre todos os objetos da lista e procura por algum que 
possua a representação em String igual ao valor que foi enviado, já que este 
foi gerado justamente pelo método getAsString. Dessa forma, consegui- 
mos retornar as instâncias do objeto em questão — no nosso caso, o Author 
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-, e poupar todo aquele código de conversão que estava no nosso Managed 
Bean. 


Associando o Converter com o componente 


r4 


Por fim, para que o JSF use o nosso conversor mágico, é necessário 
associá-lo com o componente na tela. 


<h:selectManyListbox value="#{adminBooksBean. product .authors}" 
converter="entityConverter"> 


<h: selectManyListbox 
Só que ainda não demos nenhum identificador para nosso Converter. 


@FacesConverter ("entityConverter") 
public class EntityListConverter implements Converter { 


Para fechar com chave de ouro, precisamos apenas fazer a ultima altera- 
ção. Durante o uso da tag select Items, fizemos referência a propriedade 
id do objeto do tipo Author. 


<f:selectItems value="#{authorsList.get()}" var="author" 
itemLabel="#{author.name}" itemValue="#{author.id}" /> 


Só que agora estamos usando um converter que sempre pega o id das 
entidades da JPA. Da maneira como esta, nosso Converter vai procurar 
por um atributo anotado com GId na classe Integer, e não na Author. 
Vamos promover essa alteração. 


<f:selectItems value="#{authorsList.get()}" var="author" 
itemLabel="#{author.name}" itemValue="#{author}" /> 
5.7 CONCLUSÃO 


Este foi um capítulo um pouco mais denso. Lidamos com os problemas de va- 
lidação e conversão, típicos do dia a dia. A parte interessante é que passamos 
por vários detalhes do JSF e da Bean Validation. 
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Uma dica que posso dar é: sempre tente buscar o que já vem pronto dentro 
do framework, mas saiba o suficiente dele para conseguir ir além, quando 
necessário. Fizemos isso em algumas situações e valeu bastante a pena. O 
Converter para Calendar eo da lista podem ser usados em qualquer projeto 
que você venha a participar. 

Acho que esse é um bom momento para você parar e refletir sobre tudo 
que foi estudado até aqui. Já trabalhamos com a JPA, CDI, JTA e bastante com 
o JSF. Ainda tem mais de JSF e de outras especificações por vir. Descanse e 
volte com toda força para continuar a leitura. 
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Upload de arquivos 


Uma característica importante das livrarias online é a disponibilização do su- 
mário dos livros que estão à venda. A Casa do Código, como não poderia 
deixar de ser, também deve oferecer essa possibilidade a seus usuários. 


6.1 RECEBENDO O ARQUIVO NO MANAGED BEAN 


Vamos começar alterando a página da Casa do Código responsável pela en- 
trada de dados de cada um dos novos livros. 


<h: form> 


<div> 
<h:outputLabel value="Capa do livro"/> 
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<h:inputFile id="summary" label="Sumario do livro"/> 
</div> 


A única mudança foi a adição do input que vai receber o arquivo que, 
neste caso, deve ser do tipo file. Agora, se tentarmos enviar os dados desse 
formulario, devemos receber a seguinte exception: 


javax.servlet.ServletException: UTO10016: 
Not a multi part request 


Not a multi part request significa que tentamos enviar o ar- 
quivo de uma forma que o JSF não consegue entender. Basicamente, o 
que acontece é que todos os dados do formulário são enviados de al- 


guma maneira, e o padrão é que eles sejam submetidos usando o formato 





application/x-www-form- urlencoded. Dessa forma, os dados são 
enviados seguindo quase as mesmas regras usadas quando utilizamos o mé- 





todo GET. Uma sequência de chaves e valores. 

A nossa situação atual exige que façamos uma alteração nesse formato, 
de modo que o arquivo possa ser integralmente passado do navegador para o 
servidor. É por isso que vamos utilizar o formato multipart /form-data. 


<h:form enctype="multipart/form-data"> 


<div> 

<h:outputLabel value="Capa do livro"/> 

<h:inputFile id="summary" label="Sumario do livro"/> 
</div> 


O atributo enctype serve justamente para indicarmos como queremos 
mandar os dados do navegador para o servidor, eo multipart/form-data 
é o jeito utilizado quando precisamos transmitir arquivos. Por exemplo, já 
existe um trabalho sendo feito para que o seu form possa enviar os dados 
pelo formato JSON. Caso fique curioso, navegue até http://www.w3.org/TR/ 
html-json-forms/. 
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Alterando o método do Managed Bean 


Agora que nosso formulário já envia o arquivo, precisamos recebê-lo e li- 
dar com ele. Faremos isso no método save da classe AdminBooksBean. O 
primeiro passo, na verdade, é fazer o binding entreo inputFile e alguma 
propriedade do nosso bean. O leitor mais atento devia até estar se pergun- 
tando qual era o motivo de não termos feito isso antes. 


<div> 
<h:outputLabel value="Sumário do livro"/> 
<h: inputFile id="summary" value="#{adminBooksBean.summary}" 
label="Sumário do livro"/> 

</div> 


Aqui, assumimos que o bean vai ter uma propriedade chamada summary. 
É justamente nela que vamos guardar o arquivo que tiver sido enviado pelo 
formulário. 


@Model 
public class AdminBooksBean { 


private Part summary; 
public void setSummary(Part summary) { 


this.cover = cover; 


public Part getSummary() { 
return cover; 


@Transactional 
public String save(){ 


System. out.println(summary.getName() + ";" 
+summary .getHeader ("content-disposition")); 
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A parte importante desse código é o atributo do tipo Part. Ele foi in- 
troduzido a partir da versão 3 da especificação de Servlets, e é a interface res- 
ponsável por representar o arquivo que foi enviado pelo formulário. 

Perceba que o nome do argumento é o mesmo nome do input que decla- 
ramos no formulário. Aqui usamos dois métodos: 


e getName () — retorna o nome do input usado no formulário; 


e getHeader () - usado para recuperar alguma informação sobre o que 
foi enviado. 


Caso nós quiséssemos recuperar o nome do arquivo, como faríamos? O 
leitor mais experiente deve estar pensando que tem algum método que já re- 
torna isso pronto, mas esse é justamente o problema. 

A interface Part é a maneira mais primitiva de tratarmos os dados envi- 
ados por meio do enctype multipart /form-data. Para ficar um pouco 
mais claro, dê uma olhada na maneira como esses dados são enviados a partir 
do navegador. 
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¥ Request Payload 


WebKit FormBoundarybD5VjnI2VannG8wt 
Content-Disposition: form-data; name="j_idt4" 





j_idt4 





WebKit FormBoundarybD5VjnI2VannGBwt 
Content-Disposition: form-data; name="j_idt4:j_idt8" 


kfjdlkfis 
————WebKit FormBoundarybD5VjniI2VannGBwt 
Content-Disposition: form-data; name="j_idt4:j_idti2" 


kUjkfdsjfkdjsk 
WebKit FormBoundarybDSVjni2VannGBwt 
Content-Disposition: form-data; name="j_idt4:j_idti6" 
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WebKitFormBoundarybD5VjnI2VannG8wf 
Content-Disposition: form-data; name="j_idt4:preco" 


200 





WebKitFormBoundarybD5VjnI2VannG8wf 
Content-Disposition: form-data; name="j_idt4:j_idt23" 


2015-06-30 
———WebK it FormBoundarybD5Vjni2VannG8wf 
Content-Disposition: form-data; name="j_idt4:j_idt27" 


3 

———WebKit FormBoundarybD5VjnI2VannGBwt 

Content-Disposition: form-data; name="j_idt4:summary"; filename="contaluz.pdf" 
Content-Type: application/pdf 


Fig. 6.1: Corpo do request para uma requisição multipart 


Para os campos que não representam arquivos, o JSF já nos ajuda bastante 
e faz a ligação direta com as propriedades do nosso modelo. Para o arquivo 
enviado, vamos ter de fazer o parse e recuperar o nome dele, infelizmente. O 
nosso código vai ficar parecido com: 


@Transactional 
public String save()f{ 


System.out.println(extractFilename 
(summary. getHeader ("content-disposition")) ; 
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private String extractFilename(String contentDisposition) { 


if (contentDisposition == null) { 
return null; 

} 

String fileNameKey = "filename="; 


int startIndex = contentDisposition. index0f (fileNameKey) ; 
if (startIndex == -1) { 
return null; 
} 
String filename = contentDisposition.substring(startIndex 
+ fileNameKey.length()); 
if (filename.startsWith("\"")) { 
int endIndex = filename.index0f("\"", 1); 
if (endIndex != -1) { 
return filename.substring(1, endIndex); 


} 
} else { 
int endIndex = filename.index0f(";"); 
if (endIndex != -1) { 
return filename.substring(0, endIndex); 
} 


} 


return filename; 


Este é justamente o tipo de código que devemos evitar ter no nosso Ma- 
naged Bean. Caso uma pessoa nova chegue ao seu projeto, ela vai perder mais 
tempo tentando entender isso do que prestando atenção no fluxo do projeto 
em si, que é o mais importante. Um pouco mais à frente, vamos usar o CDI 
para nos ajudar a deixar esse código mais coeso. 


6.2 SALVANDO O CAMINHO DO ARQUIVO 


Agora que já temos o objeto que representa o arquivo enviado em nossas 
mãos, é necessário gravá-lo em algum lugar. Vamos aproveitar também e já 
isolar esse código de recuperar o nome do arquivo e salvá-lo. 
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@Model 
public class AdminBooksBean { 


private Part summary; 
@Inject 


private FileSaver fileSaver; 


@Transactional 
public String save(){ 
String summaryPath = 
fileSaver.write("summaries", summary) ; 


package br.com.casadocodigo.loja.infra; 


@RequestScoped 
public class FileSaver { 


@Inject 
private HttpServletRequest request; 


private static final String CONTENT_DISPOSITION = 
"content-disposition"; 


private static final String FILENAME KEY = "filename="; 
public String write(String baseFolder, Part multipartFile) { 
String serverPath = request.getServletContext () 


.getRealPath("/" + baseFolder) ; 


String fileName = extractFilename(multipartFile 
. getHeader (CONTENT DISPOSITION)); 


String path = serverPath + "/" + fileName; 


try É 
multipartFile.write(path); 
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} catch (IOException e) 1 
throw new RuntimeException(e); 
} 


return baseFolder + "/" + fileName; 


private String extractFilename(String contentDisposition) 1 
if (contentDisposition == null) { 
return null; 
} 
int startIndex = contentDisposition 
. indexOf (FILENAME_KEY) ; 
if (startIndex == -1) É 
return null; 
} 
String filename = contentDisposition 
. substring (start Index 
+ FILENAME_KEY.length()); 
if (filename.startsWith("\'"")) 1 
int endIndex = filename.indexOf("\"", 1); 
if (endIndex != -1) 1 
return filename.substring(1, endIndex); 


} 
} else { 
int endIndex = filename. index0f(";"); 
if (endIndex != -1) 1 
return filename. substring(0, endIndex) ; 
} 


} 


return filename; 


Dê uma respirada e olhe com cuidado para o código. Perceba que não 
fizemos nada demais, apenas criamos outra classe responsável por gravar o 
arquivo em uma pasta da nossa aplicação. A ideia é não deixar que esse código 
atrapalhe o fluxo do método save no nosso Managed Bean. Além disso, é 
necessário criar o atributo summaryPath na classe Book, juntamente com 
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o seu getter e setter. 
Dessa forma, caso seja necessário criar um link para o sumário, basta que 
façamos algo parecido com o que segue: 


<a href="${book.summaryPath}">Sumario do livro</a> 


Podemos inclusive acrescentar esse link na listagem atual dos livros. 


<h: column> 
<f:facet name="header">Sumario</f :facet> 
<h:outputLink value="#{request.contextPath} 
/#{book.summaryPath}"> 
#{book. summaryPath} 
</h: outputLink> 
</h:column> 


6.3 GRAVANDO OS ARQUIVOS FORA DO SERVIDOR 
WEB 


Nossa lógica de upload grava os novos arquivos em uma pasta dentro da pró- 
pria aplicação web. O problema dessa abordagem, mesmo quando estamos 
em ambiente de desenvolvimento, é que, a cada nova alteração que temos no 
projeto, a nossa IDE força um hot deploy no servidor. Em geral, o hot deploy 
destrói a aplicação que estava no servidor e cria uma nova, fazendo com que 
percamos os arquivos que já tinham sido enviados. 

Além disso, um fato que incomoda o desenvolvedor é perceber que os 
arquivos enviados não ficam exatamente dentro do projeto que ele está visu- 
alizando - por exemplo, no Eclipse -, mas na instalação do servidor que foi 
escolhida. Para simplificar tudo isso, facilitando inclusive o processo de de- 
ploy que discutiremos mais para o fim do livro (capítulo 16), é que podemos 
usar um serviço como o Amazon S3. 

Basicamente, a Amazon fornece um serviço onde podemos enviar nos- 
sos arquivos, e estes ficam disponíveis para serem acessados pela web. Eles 
possuem servidores dedicados só para isso. 
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Integração com o Amazon S3 


Para quem estiver interessado nessa opção, a primeira coisa que devemos 


fazer é alterar o código que está na classe FileSaver, que é a responsável 


por gravar o arquivo. 


public class FileSaver 1 
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public String write(String baseFolder, 
Part multipartFile) 1 
AmazonS3Client s3 = client(); 
String fileName = extractFilename(multipartFile 
.getHeader (CONTENT DISPOSITION)); 
try { 
s3.putObject ("casadocodigo", fileName, 
multipartFile.getInputStream() , 
new ObjectMetadata()); 


return "https://s3.amazonaws.com/casadocodigo/" 
+fileName; 


} catch (AmazonClientException | IOException e) { 
throw new RuntimeException(e); 


private AmazonS3Client client() { 
AWSCredentials credentials = new BasicAWSCredentials( 


); 
AmazonS3Client newClient = 
new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions(new S3ClientOptions() 
.withPathStyleAccess(true) ); 
return newClient; 
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Perceba que temos mais códigos relativos à integração com a Amazon do 
que relacionado ao CDI ou o JSF em si. De tudo o que foi escrito anterior- 
mente, as linhas mais importantes são as que estão logo a seguir: 


AmazonS3Client s3 = client(); 


s3.putObject("casadocodigo", fileName, 
multipartFile.getInputStream() , 
new ObjectMetadata()); 


O objeto do tipo AmazonS3Client encapsula todo a lógica e o proto- 
colo de comunicação com a Amazon. O nosso único trabalho é passar os 


parâmetros. 


e O primeiro é a pasta remota onde o arquivo vai ser salvo, também co- 
nhecida como bucket; 


e O segundo é o nome do arquivo; 


* O terceiro é alguma implementação da classe InputStream, que re- 


almente representa o arquivo; 


e O quarto são informações extras como: data de expiração do arquivo e 
qualquer outra informação que seja específica da aplicação. 


A outra parte do código é a mesma para qualquer integração que você vá 
fazer com a Amazon. Sempre precisamos criar um objeto que contém as cre- 
denciais de acesso, para garantir que só o dono da conta possa fazer uploads 
para o bucket. 
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private AmazonS3Client client() { 
AWSCredentials credentials = new BasicAWSCredentials( 


); 
AmazonS3Client newClient = new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions(new S3ClientOptions() 
.withPathStyleAccess(true) ); 
return newClient; 


Basicamente, estas seriam as alterações que teríamos de fazer no nosso 
código. Como deixamos encapsulada a lógica de gravação do arquivo, não 
somos obrigados a alterar nenhuma linha do nosso Controller. 


Simulando o S3 localmente 


O empecilho com a solução apresentada é que vamos ter de realmente 
criar um conta na Amazon para conseguir realizar nossos testes, o que é com- 
pletamente inviável. Para resolver este problema, existe um projeto chamado 
S3 Ninja, que pode ser encontrado em http://s3ninja.net/. 

Ele foi criado com o objetivo de servir como um emulador para o S3 real, 
da Amazon. O S3 Ninja é uma aplicação web escrita em Java que sobe um ser- 
vidor que aceita requisições vindas do próprio SDK da Amazon. Justamente 
o que estávamos procurando. Uma parte muito boa é que o seu uso é bem 
simples. 

O primeiro passo é realizar o download do .zip, bastando aces- 
sar o endereço https://oss.sonatype.org/content/groups/public/com/scireum/ 
s3ninja/2.3/s3ninja-2.3-zip.zip. 

Você também pode encontrar o link no readme do GitHub do projeto, 
em https://github.com/asouza/casadocodigojavaee. 

Uma vez que você baixou o projeto, descompacte-o em uma pasta de sua 
preferência. Ainda dentro da pasta descompactada, precisamos criar um es- 
trutura simples de subpastas que vão simular os buckets da Amazon. Vamos 
criar primeiro a pasta data e, dentro dela, criaremos outra pasta, chamada 
s3. A estrutura final vai ficar parecida com a mostrada na figura a seguir: 
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META-INF 
maven 
app 


assets 
ninja 
view 

data 

L- s3 

lib 

logs 


Fig. 6.2: Estrutura de pastas do S3 Ninja 


Agora que a estrutura está criada, basta iniciarmos o servidor do S3 Ninja. 
java IPL 
Perceba que IPL é justamente um arquivo Java compilado que já vem na 


raiz do diretório descompactado. Após executar o comando, você deve ver a 
seguinte saída: 


INITIAL PROGRAM LOAD 


IPL from: /Users/alberto/ambiente/servidores/s3ninja-2.3-zip 
IPL completed - Loading Sirius as stage2... 


Opening port 9191 as shutdown listener 


O servidor está rodando no endereço http://localhost:9444/. Você pode 
acessá-lo pelo navegador. 


S3 ninja 


S3 ninja emulates the S3 AP! for development and testing purposes 


ither provid lability nor 





tere | License Implemented API 


Access: Logs 


Fig. 6.3: Tela de boas-vindas do S3 Ninja 
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Agora que o nosso emulador está rodando, precisamos alterar o código 
de configuração de acesso à Amazon e fazê-lo apontar para o servidor local. 


private AmazonS3Client client() { 
AWSCredentials credentials = new BasicAWSCredentials( 
); 
AmazonS3Client newClient = new AmazonS3Client (credentials, 
new ClientConfiguration()); 
newClient.setS3ClientOptions(new S3ClientOptions() 
.withPathStyleAccess(true) ); 


//nova linha 
newClient.setEndpoint ("http://localhost :9444/s3") ; 
return newClient; 


Pronto! Quando cadastrarmos um novo livro, o arquivo do sumário vai 
ser gravado na pasta data/s3/casadocodigo/nomedoarquivo, no local 
que você escolheu para executar o S3 Ninja. Perceba que também alteramos 
o retorno do método write, da classe FileSaver. 


public String write(String baseFolder, Part multipartFile) { 
AmazonS3Client s3 = client(); 
String fileName = extractFilename(multipartFile 
. getHeader (CONTENT_DISPOSITION) ) ; 
try { 
s3.putObject("casadocodigo", fileName, 
multipartFile.getInputStream(), 
new ObjectMetadata()); 


//url de acesso ao arquivo 
return "https://s3.amazonaws.com/casadocodigo/" 


+fileName+"?noAuth=true"; 


} catch (AmazonClientException | IOException e) { 
throw new RuntimeException(e) ; 
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A ideia é que nosso método já retorne o endereço de acesso ao arquivo 
enviado, para que possamos usá-lo nos links do nosso sistema. 


Isolando a criação do AmazonS3Client 


A nossa alteração nos levou a deixar o código de criação do objeto de 
acesso à Amazon misturado com o código da classe FileSaver. Como já 
tem sido a nossa prática, quando, por exemplo, recebemos injetado o DAO, o 
nosso objetivo nesse código é usar o cliente da Amazon, e não ficar criando. 
Então, vamos começar recebendo um objeto do tipo AmazonS3Client em 
vez de criá-lo. 


public class FileSaver { 


@Autowired 
private AmazonS3Client s3; 


public String write(String baseFolder, 
MultipartFile multipartFile) { 
String fileName = extractFilename(multipartFile 
. getHeader (CONTENT DISPOSITION)); 


try É 
s3.putObject ("casadocodigo",fileName, 
multipartFile.getInputStream(), 
new ObjectMetadata()); 


return "http://localhost :9444/s3/casadocodigo/" 
+fileName+"?noAuth=true"; 


} catch (AmazonClientException | IOException e) { 
throw new RuntimeException(e); 
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Para este código funcionar, assim como fizemos quando foi necessário 


injetar o objeto do tipo FacesContext, precisamos criar um método para 


criar um objeto do tipo AmazonS3Client. 


package br.com.casadocodigo.loja. infra; 


import 


import 
import 
import 
import 
import 


public 


javax.enterprise.inject.Produces; 


com.amazonaws.ClientConfiguration; 
com.amazonaws.auth.AWSCredentials; 
com.amazonaws.auth.BasicAWSCredentials; 
com.amazonaws.services.s3.AmazonS3Client ; 
com. amazonaws.services.s3.53ClientOptions; 


class AmazonS3ClientProducer { 


@Produces 
public AmazonS3Client s3NinjaQ { 


AWSCredentials credentials = new BasicAWSCredentials( 


); 

AmazonS3Client newClient = 

new AmazonS3Client (credentials, 

new ClientConfiguration()); 
newClient.setS3ClientOptions(new S3ClientOptions() 

.withPathStyleAccess(true) ); 
newClient.setEndpoint ("http://localhost :9444/s3") ; 
return newClient; 


Um detalhe interessante é que esse nosso método produtor não deve ter 


nenhuma anotação de escopo. O problema é que a classe AmazonS3Client 


possui métodos marcados como final, ea especificação do CDI exige que 


todos os comportamentos da classe e, inclusive a classe, não estejam marca- 


dos como final, para suportar a injeção de objetos baseados em escopos 


diferentes do Dependent. 
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Agora você tem duas opções para salvar os arquivos enviados pelos seus 
usuários. Este autor sugere que você sempre guarde o arquivo em um local 
fora do servidor web. A complexidade adicionada ao projeto é compensada 
pela flexibilidade de manter os arquivos entre reloads da aplicação, em tempo 
de desenvolvimento. 

Além disso, a instalação no ambiente de produção vai ser facilitada, já que 
você não vai ter de se preocupar em manter os arquivos que já tenham sido 
enviados pelos usuários. Tudo vai estar em um lugar separado. 

Um detalhe simples, mas muito importante: lembre-se sempre de subir 
o servidor do S3 Ninja antes de rodar sua aplicação! 


6.4 CONCLUSÃO 


Neste capítulo, focamos unicamente no upload de arquivos. Essa é uma fun- 
cionalidade muito comum nas aplicações, mas muitas vezes esquecemos de 
olhar com detalhes para entender exatamente como funciona. O interessante 
é que tudo foi muito direto, não tivemos que perder tempo com nenhuma 
configuração extra. Basicamente, usamos tudo o que já estava pronto nas úl- 
timas versões das especificações do JSF e de Servlets. 

Não pare agora, já vá para o próximo capítulo no qual vamos realizar o fe- 
chamento de uma compra. Vamos implementar um Carrinho, ver um pouco 
mais dos escopos do CDI e deixar o terreno preparado para realizarmos uma 
integração com outro sistema. 
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CAPITULO 7 


Carrinho de compras 


Já temos o cadastro de livros e a sua listagem na loja da Casa do Código, en- 
tão chegou o momento de implementarmos o processo de compra. Para co- 
meçarmos essa fase, precisamos, primeiramente, possibilitar que os usuários 
escolham os livros que mais lhes interessam e os coloquem em um carrinho 
de compras. 


7.1 EXIBINDO OS LIVROS NA PÁGINA INICIAL 


Na Casa do Código, os visitantes conseguem navegar para as páginas de de- 
talhes dos livros a partir da listagem exibida na página inicial do site. 


71. Exibindo os livros na página inicial Casa do Código 
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Fig. 7.1: Listagens da home 


Perceba que temos duas listagens: uma com os últimos lançamentos e 
outra que exibe os últimos livros com preços promocionais. Nosso primeiro 
desafio é justamente reproduzir essa página. 

Aqui, para ficar claro que realmente estamos reproduzindo o site da Casa 
do Código, será usado o mesmo HTML construído por eles. Como o código 
da página é relativamente grande, para ver a página completa, o leitor pode 
navegar até o link https://github.com/asouza/casadocodigojavaee/blob/master/ 

src/main/webapp/site/index.xhtml. 

No trecho a seguir, veja algumas partes importantes. Apenas para fins de 

organização, esta deve ser criada em uma nova pasta chamada site, com o 

nome de index.xhtml. 


<ui:repeat var="book" value="#{homeBean. lastReleases () }"> 
<li class="col-left"><a href="/products/livro-plsql" 
class="block clearfix"> <img width="170" height="240" 
src="#{book.coverPath}" 
alt=" #{book.title}" title="#{book.title}"/> 
<h2 class="product-title">#{book.title}</h2> <small 
class="buy-button">Lan&#231;amento!</small></a> 
</li> 
</ui:repeat> 
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<ui:repeat var="book" value="#{homeBean.olderBooks() }"> 
<li><a href="/products/livro-laravel-php" 
class="block clearfix"> 
<h2 class="product-title">#{book.title}</h2> 
<img width="143" height="202" 
src="#{book.coverPath}" 
alt="#{book.title}" 
title="#{book.title}"/><small 
class="buy-button">Compre</smal1> 
</a></1i> 
</ui:repeat> 


A página basicamente é um HTML, e usamos a tag repeat para im- 
primir os livros retornados pelos métodos em questão. Para concentrar as 
lógicas relativas à nossa home, foi criada a classe HomeBean. 


package br.com.casadocodigo. loja.managedbeans.site; 
//imports 


@Model 
public class HomeBean { 


@Inject 
private BookDAO bookDao; 


public List<Book> lastReleases(){ 
return bookDao.lastReleases(); 


public List<Book> olderBooks() { 
return bookDao.olderBooks(); 


Uma simples classe anotada com @Model, nada que vocé ja nao tenha 
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visto. Para o nosso código ficar completamente funcional, precisamos tam- 
bém adicionar os novos métodos na classe BookDAO. 


package br.com.casadocodigo.loja.daos; 


//imports 


public class BookDAO 1 


@PersistenceContext 
private EntityManager manager; 


public List<Book> lastReleases() { 
return manager.createQuery("select b from Book b where 
b.releaseDate <= now() order by 
b.id desc",Book.class) 
.setMaxResults (3) .getResultList (); 


public List<Book> olderBooks() { 
return manager.createQuery("select b from 
Book b",Book.class) 
.setMaxResults (20) .getResultList (); 


Aqui, usamos um pouco mais da JPA para conseguir fazer nossas que- 
ries. Um detalhe muito importante quando estamos trabalhando com a JPA 
é: pense na suas consultas como se estivesse realmente trabalhando com os 
objetos! 

Claro que é importante conhecer SQL, mas quando você aceita trabalhar 
com uma ferramenta de Mapeamento Objeto-Relacional (ORM), é interes- 
sante que a maioria das suas queries consigam tirar proveito das vantagens 
oferecidas pela JPQL. 
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Pronto, com isso já conseguimos exibir todos os nossos livros cadastra- 
dos. Um detalhe importante para essa página funcionar bem é que todos os 
produtos cadastrados estejam com uma imagem associada. Para facilitar, sim- 
plesmente rode um comando SQL que atualize todas as capas para alguma 
imagem previamente cadastrada. Veja um exemplo: 


update Book set coverPath = 
“http: //localhost:9444/s3/casadocodigo/ 
covers games-android-featured medium. png?noAuth=true’ ; 


Um outro ponto importante é que, caso você tenha optado por usar o S3 
Ninja, seu servidor deve estar rodando. Então, lembre-se de ir na pasta de 


instalação e rodar o seguinte comando: 


java IPL 


Pronto, já temos uma página inicial igual a da Casa do Código! E melhor 
ainda, não foi necessário usar nada de novo, trabalhamos apenas com o que 
já estudamos e conseguimos reproduzir uma aplicação bastante conhecida no 
mercado. 


7.2 NAVEGANDO PARA O DETALHE DO PRODUTO 


Agora que já temos a listagem dos livros, é necessário que os usuários da apli- 
cação consigam navegar para a página de detalhes do livro. É nessa outra 
página que ele vai encontrar informações como: preço, autores e resumo do 
conteúdo da obra. Perceba que, atualmente, o link para os detalhes está fixo 
em nossa listagem. 


<ui:repeat var="book" value="#{homeBean.lastReleases() }"> 
<li class="col-left"><a href="/products/livro-plsql" 


</li> 
</ui:repeat> 


<ui:repeat var="book" value="#{homeBean.olderBooks()}"> 
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<li><a href="/products/livro-laravel-php" ...> 


</a></1i> 
</ui:repeat> 


O href esta sempre apontando para uma URL fixa, e precisamos deixar 
isso dinâmico. Essa é uma parte tranquila de resolver. Vamos dar uma olhada: 


<ui:repeat var="book" value="#{homeBean.lastReleases() }"> 
<li class="col-left"><a 
href="#{request .contextPath}/site/ 
detalhe.xhtml?id=#{book.id}" 


</li> 
</ui:repeat> 


<ui:repeat var="book" value="#{homeBean.olderBooks()}"> 
<li><a 
href="#{request .contextPath}/site/ 
detalhe.xhtml?id=#{book.id}" 
ne 


</a></1i> 
</ui:repeat> 


Simplesmente apontamos agora para o endereço detalhe. xhtml, res- 
ponsável por exibir os detalhes do livro. Temos também de passar o parâme- 
tro indicando qual o id do livro que estamos buscando. Assim, usamos o 
request. contextPath para sempre garantir que estamos referenciando a 
raiz do contexto da nossa aplicação. 

Agora é necessário que tenhamos essa página, para que esse nosso link 
funcione. Mais uma vez, vamos usar o layout original da Casa do Código e, 
como o HTML é muito grande, vamos apenas deixar os trechos importan- 
tes aqui no livro. O conteúdo inteiro pode ser encontrado em https://github.com/ 
asouza/casadocodigojavaee/blob/master/src/main/webapp/site/detalhe.xhtml. 

Essa página deve ser criada com o nome de detalhe.xhtml, e deve 
ficar na pasta site. 
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<html xmins:h="http://java.sun.com/jsf/html" 
xmlns:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:pt="http://xmlns.jcp.org/jsf/passthrough"> 


<head> 


<title>#{productDetailBean.book.title}</title> 
</head> 


<header> 
<div id="product-overview" class="container"> 

<img width="280px" height="395px" 
src="#{productDetailBean.book.coverPath}" 
class="product-featured-image" 
alt="#{productDetailtBean. book.description}"/> 

<hi class="product-title"> 
#{productDetailBean.book.title} 

</hi> 

<p class="product-author"> 

<span class="product-author-link"> 


<ui:repeat var="author" 
value="#{productDetailBean. book. authors}"> 
#{author .name}| 

</ui:repeat> 


</span> 
</p> 


<p class="book-description"> 


#{productDetailBean.book.description} 
</p> 
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</div> 
</header> 


<section class="author product-detail"> 
<h2 class="section-title"> 


<ui:repeat var="author" 
value="#{productDetailBean.book.authors}"> 
#{author .name}| 

</ui:repeat> 


</h2> 
<span> 


<p class="book-description"><img class="author-image" 
src="" alt="" style="float: left; margin-right: 10px; "/> 
<a>Descricao sobre os autores</a>.</p> 


</span> 
</section> 


<section class="data product-detail"> 
<h2 class="section-title">Dados do livro:</h2> 
<p>Número de paginas: 
<span> 
#{productDetailBean. book.number0fPages} 
</span></p> 


<p></p> 
<p> 
Data de publicação: 
t(productDetailBean.book.releaseDate. time) 
</p> 


De novo, pelo menos até agora, é uma página apenas com códigos que já 
estudamos. Para lidar com a responsabilidade de carregar o produto, criamos 
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um novo bean, chamado ProductDetailBean. 


package br.com.casadocodigo. loja.managedbeans.site; 
//imports 


@Model 
public class ProductDetailBean { 


@Inject 
private BookDAO bookDAO; 
private Book book; 


@PostConstruct 
public void loadBook(){ 
this.book = bookDAQ.findById(id) ; 


public Book getBook() { 
return book; 


Recebendo parâmetros e executando ações em requisições via GET 


O leitor mais atento deve estar se perguntando de onde veio o id que está 
sendo usado para carregar o produto, e esse é um ótimo questionamento! A 





requisição que chega na página de detalhe vem a partir de um GET, sendo 
que, até o momento, qualquer método dos nossos beans só foi invocado a 
partir de requisições via POST. 

Há muito tempo atrás, ainda na primeira versão do JSE, isso seria um pro- 
blema para nós. Seríamos obrigados a fazer um POST apenas para satisfazer o 
framework e, com isso, a navegabilidade do nosso site estaria comprometida. 
Por exemplo, todos os links que são acessados via POST não são indexados 
pelo Google, o que seria extremamente prejudicial para a Casa do Código. 

Percebendo que isso era um problema, a versão 2.0 do JSF trouxe o su- 
porte para o recebimento de parâmetros que viessem a partir de um novo 
request. Assim, foi criada a taglib viewParam, que fica no pacote core, 
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bastando usa-la dentro de uma outra, chamada metadata. 


Vamos alterar nossa pagina de detalhe: 


<html xmlns:h="http://java.sun.com/jsf/html" 


xmlns:f="http://xmlns.jcp.org/jsf/core" 
xmlns="http://www.w3.org/1999/xhtm1" 
xmlns: pt="http://xmlns.jcp.org/jsf/passthrough"> 


<f:metadata> 
<f:viewParam id="id" name="id" 
value="#{productDetailBean.id}"/> 
</f :metadata> 


Podemos receber o id e associá-lo com nosso bean, por meio dos méto- 


dos de acesso. 


package br.com.casadocodigo.loja.managedbeans.site; 


//imports 


@Model 
public class ProductDetailBean { 
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private BookDAO bookDAO; 
private Book book; 
private Integer id; 


public void setId(Integer id){ 
this.id = id; 


public Integer getId() { 
return id; 


@PostConstruct 
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public void loadBook(){ 
this.book = bookDAO.findById(id); 


public Book getBook() { 
return book; 


Caso tentemos rodar este código, ainda receberemos uma exception. O 
problema é que o binding do parâmetro com seu bean só acontece na fase 
UPDATE MODEL VALUES do ciclo de vida do JSF. Este é o momento que o 

















JSF vai setar os valores no seu bean; enquanto que a invocação do método 
anotado com @PostConstruct, nesse caso, acontece uma fase antes, na 
PROCESS VALIDATIONS. 





O momento que o bean é instanciado vai depender do seu uso dentro 
da página. Por exemplo, na home, ele só é instanciado no momento que o JSF 
vai escrever o HTML para o navegador, já que só o usamos para consumir 
informações. Já na página de detalhes, precisamos setar o id passado como 
argumento, assim, ele será instanciado na fase de validação para que qualquer 
verificação ou conversão necessária seja realizada. 

É importante sempre lembrar das fases do JSF, conhecer um pouco de 
cada uma delas pode poupar bastante uma dor de cabeça na hora de desven- 
dar bugs na aplicação. 

Uma maneira simples de resolver este problema seria tirar o código do 
método anotado com @PostConstruct, e colocá-lo dentro do método 
setId. Só que, a partir do JSF 2.2, foi criada uma nova tag, chamada 
viewAction. O objetivo é que ela seja usada em páginas de um sistema 





escrito em JSF que foram acessadas via GET. 


<f:metadata> 
<f:viewParam id="id" name="id" 
value="#{productDetailBean.id}"/> 
<f:viewAction action="#{productDetailBean.1loadBook () }"/> 
</f:metadata> 
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Por padrao, a viewAct ion permite que invoquemos algum método do 
nosso bean na fase INVOKE_APPLICATION, justamente a usada pelo JSF 


T 





para invocar nossas lógicas. Com isso, garantimos que o carregamento do 
livro só será feito quando o id já tiver sido setado. 
Veja como o código final da classe ProductDetailBean deve ficar: 


package br.com.casadocodigo.loja.managedbeans.site; 
//import 


@Model 
public class ProductDetailBean { 


@Inject 

private BookDAO bookDAO; 
private Book book = new Book(); 
private Integer id; 


public void setId(Integer id) 1 


this.id = id; 


public Integer getId() { 
return id; 


public void loadBook() 1 
this.book = bookDAO.findById(id) ; 


public Book getBook() { 
return book; 


Para fechar, precisamos só adicionar o método findById na classe 
BookDAO. 


package br.com.casadocodigo.loja.daos; 
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//import 
public class BookDAO { 


@PersistenceContext 
private EntityManager manager; 


public Book findById(Integer id) { 
return manager.find(Book.class, id); 


7.3 LIDANDO COM LAZYINITIALIZATIONEXCEPTION 


Caso o leitor tenha acessado a página de detalhe do livro, vai perceber que 
uma exception foi lançada. 


javax.servlet.ServletException: failed to lazily initialize a 
collection of role: br.com.casadocodigo.loja.models.Book.authors, 
could not initialize proxy - no Session 


O problema acontece exatamente na linha a seguir, da página 
detalhe.xhtml: 


<ui:repeat var="author" 
value="#{productDetailBean. book.authors}"> 


De novo temos um problema relacionado ao ciclo de vida, só que agora do 





EntityManager. O método getAuthors da classe Book usa um atributo 
mapeado com a annotation @ManyToMany. Por default, a implementação da 
JPA vai tentar carregar essa coleção apenas no momento do seu uso efetivo. 
Para que isso aconteça, é necessário que um SQL seja disparado no banco 





e, consequentemente, 0 EntityManager esteja aberto para possibilitar essa 
operação. 
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É justamente nesse ponto que o ciclo de vida nos passa uma rasteira. Por 





padrão, o EntityManager gerenciado pelo servidor de aplicação é criado 
no momento em que algum método da classe que o recebeu injetado for invo- 
cado. Só que todos os objetos que são carregados dentro do escopo do método 
deixam de ser gerenciados logo após o fim de sua execução, deixando o objeto 
em um estado chamado detached. Esse comportamento é o que nos leva 
ao problema que estamos vivenciando. 

Uma maneira de alterar esse comportamento é definindo um escopo de 
transação. Por exemplo, caso tivéssemos anotado o método loadBooks com 





@Transactional,o EntityManager viveria até o fim do método, o que, 
infelizmente, também não é o suficiente para nós. Sem contar que a annota- 
tion @Transactional deve ser utilizada para demarcar métodos que real- 
mente precisem de uma transação, como fizemos no momento de salvar um 
livro. 


EntityManager extended e o EJB Stateful 


Já existem soluções que podem ser usadas para resolver este problema. As 
opções mais comuns são: 


e Criar um filtro da especificação de Servlets que comece uma transação 
no início do request, e que feche no fim; 





e Criar um produtor de EntityManager do CDI e associá-lo com o 
escopo de requisição; 


* Planejar todas as queries do sistema com o uso de fetch joins. Dessa 
forma, tudo o que é lazy já é carregado. 


O planejamento de queries é a solução que mais agrada este autor. Ela já 
vem sendo utilizada durante o livro, só não tinha sido deixado claro que era 
por este motivo. 


public class BookDAO 1 


@PersistenceContext 
private EntityManager manager; 
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public List<Book> list () { 
return manager.createQuery ("select b from Book b join 
fetch b.authors", 
Book. class) .getResultList (); 


A parte negativa dessa solução é que ela aumenta consideravelmente a 
complexidade das queries que serão escritas no sistema, já que o tempo todo 
teremos de decidir exatamente o que precisa ser carregado para cada objeto. 

Para balancear essa equação, podemos usar um outro recurso, já provido 
pela especificação. Primeiro, temos de deixar clara a nossa necessidade. Pre- 





cisamos que o EntityManager fique aberto enquanto estivermos usando o 
objeto criado a partir da classe Product Det ai 1Bean, uma vez que ele vive 
durante todo request. 

A primeira atitude que podemos tomar é a de alterar a maneira que o 
EntityManager é associado ao objeto do tipo BookDAO. Atualmente, ape- 





sar de não termos configurado, ele é sempre ligado a uma transação. 


public class BookDAO { 


@PersistenceContext (type=PersistenceContextType. TRANSACTION) 
private EntityManager manager; 


Quase nunca especificamos o atributo type, já que o padrão é 





PersistenceContextTyp . TRANSACTION e, normalmente, é o que ne- 
cessitamos mesmo. Agora é necessário aumentar o seu tempo de vida para 


ele ir além de uma transação ou apenas da execução de um método. 


public class BookDAO { 


@PersistenceContext (type=PersistenceContextType.EXTENDED) 
private EntityManager manager; 
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E justamente para isso que serve o 




















PersistenceContextType.EXTENDED. Esse tipo de EntityManager 





deve ser injetado quando é necessário que os objetos carregados por ele 
permaneçam gerenciados enquanto o objeto que solicitou a injeção estiver 
sendo controlado pelo container. Isso já deveria ser o suficiente, uma 
vez que, como o nosso DAO não declarou nenhum escopo do CDI, é 
assumido que ele é Dependent. Como ele está sendo injetado dentro 
do ProductDetailsBean, deveria ficar vivo enquanto tal bean também 
estivesse. 


Só que, apenas por uma questão da especificação, uma classe que declara a 





necessidade de um EntityManager estendido precisa também ser anotada 
com @Stateful. 


@Stateful 
public class BookDAO { 


@PersistenceContext (type=PersistenceContextType. EXTENDED) 
private EntityManager manager; 


Classes anotadas com @Stateful automaticamente são tratadas pelo 
container como Enterprise Java Beans, e elas ficam vivas dentro do container 
enquanto o objeto que pediu sua injeção também estiver. Como, em geral, os 
beans do JSF vivem no escopo de requisição, os seus EJBs stateful também 
viverão. 

Pronto, agora podemos acessar a página de detalhes, pois 
tudo deve funcionar normalmente. Resolver o problema do 





LazyInitializationException dessa forma não é uma aborda- 





gem normalmente encontrada, mas este autor acredita que ela é a mais 
simples e poderosa que temos. 
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EJB, O ANTIGO CENTRO DA ESPECIFICAÇÃO 


Antes da chegada do CDI, os EJBs eram o centro da especificação. 
Quando era necessário usar os recursos providos pelo servidor de apli- 
cação, era obrigatório transformar nosso objeto em um EJB. Hoje em dia, 
ainda vemos isso em alguns casos, mas a tendência é cada vez mais que 
simples objetos possam receber qualquer recurso fornecido pelo servi- 
dor. 











7.4 SERA QUE O MELHOR É O DAO SER UM EJB STATE- 
FUL? 


A nossa solução, apesar de envolver muita teoria, ficou bem simples. Só tem 
um ponto que ainda pode incomodar. O DAO sabe que vai ser usado em um 





cenário que exige a extensão do ciclo de vida do EntityManager. Só que 
esse requisito tem muito mais relação com o nosso bean do JSF do que com 
DAO em si. 

Um objeto dessa mesma classe já é usado em outros cenários na 
nossa aplicação, como por exemplo, para salvar um novo livro ou 
fazer a listagem. Para essas situações, não foi necessário usar o 




















PersistenceContextType.EXTENDED. 

Para tentarmos melhorar essa situação, podemos optar por uma solução 
não convencional. Preciso deixar claro para você, leitor, que: o que vou mos- 
trar agora não é normalmente encontrado mundo a fora, mas me sinto na 
obrigação de mostrar uma estratégia que considero possuir um design me- 


lhor. 


Como é o bean do JSF que está definindo o tempo de vida necessário do 





EntityManager, podemos transformá-lo em um EJB stateful em vez de 
DAO. 


@Model 
OStateful 
public class ProductDetailBean { 
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@PersistenceContext (type=PersistenceContextType. EXTENDED) 
private EntityManager manager; 


private BookDAO bookDAO; 
private Book book; 


@PostConstruct 
private void loadManager Ot 
this.bookDAO = new BookDAO (manager) ; 


Perceba que, além dessa mudanca, também paramos de injetar o 
ProductDAO. Agora, ele é criado manualmente no método anotado com 


@PostConstruct. 





A ideia é que nós passamos para o DAO o Ent ityManager estendido. 
Dessa forma, você pode receber o DAO injetado automaticamente pelo con- 
tainer em situações comuns, mas também pode usar o mesmo DAO em situ- 





ações que necessitem deum EntityManager estendido. O máximo que vai 
acontecer é você precisar instanciar alguns DAOs manualmente, mas nada 
que seja muito complicado. 

Durante o restante do livro, será sugerido que você use essa abordagem, 
mas fique à vontade para refletir e usar a qual se encaixa melhor nos seus 
projetos. 


Só precisamos alterar a classe BookDAO para ela também suportar o re- 





cebimento de um EntityManager pelo construtor. 


public class BookDAO { 


@PersistenceContext 
private EntityManager manager; 


public BookDAO(){ 


144 


Casa do Código Capítulo 7. Carrinho de compras 





public BookDAO(EntityManager manager) { 
this.manager = manager; 


Como a annotation @PersistenceContext nao pode ser usada em 





parâmetros, somos obrigados a manter a injeção via atributo privado. Tam- 
bém é necessário manter o construtor sem argumentos, para que o objeto seja 
instanciado e, posteriormente, a injeção feita. 


O lado ruim dessa solução está justamente no fato de você ter de instan- 





ciar os DAOs na mão, além de receber um EntityManager que apenas é 
repassado para a frente. Como falei anteriormente, fique à vontade para re- 
fletir e decidir a maneira que melhor se encaixar nas suas necessidades. 


7.5 FORMATANDO A DATA DE PUBLICAÇÃO 


No fim da nossa página de detalhes, estamos exibindo a data de publicação 
do livro. 


<p>Data de publicação: #{productDetailBean.book.releaseDate.time} 


Por mais que funcione, a saída gerada não é exatamente a que esperamos. 
Para nos ajudar nesse tipo de cenário, podemos usar a tag output Text junto 
com a tag de conversão de datas. 


<p>Data de publicação: <h:outputText 
value="#{productDetailBean.book.releaseDate.time}"> 
<f:convertDateTime pattern="dd/MM/yyyy"/> 

</h: outputText></p> 


A outputText simplesmente imprime o valor passado como argu- 
mento para o atributo value. O interessante é que podemos associar a tag 
convertDateTime e, com isso, o JSF já vai formatar o valor do jeito que 
precisamos. Essa é uma ótima prática, pois estamos usando o framework exa- 
tamente no ponto onde é necessário. 
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7.6 CARRINHO DE COMPRAS E O ESCOPO DE SESSÃO 


Agora que já conseguimos navegar para a página de detalhes do livro, pode- 
mos começar a implementar a funcionalidade de adicioná-los ao carrinho de 
compras. Vamos apenas relembrar o trecho do detalhe. xntml responsável 
por isso. 


<form action="/cart/add" method="post" class="container"> 
<ul id="variants" class="clearfix"> 
<li class="buy-option"> 

<input type="radio" name="id" 
class="variant-radio" 
id="product-variant-#{productDetailBean.book.id}" 
value="#{productDetailBean.book.id}" 

checked="checked" /> 


<label class="variant-label" 
for="product-variant-#{productDetailBean 
. book. id}"> 
E-book + Impresso 
</label> 


<small class="compare-at-price"> 
R$ #{productDetailBean. book. price} 
</small> 


<p class="variant-price"> 
R$ #{productDetailBean. book. price} 
</p> 
</li> 
</ul> 


<button type="submit" class="submit-image icon-basket-alt" 
title="#{productDetailBean.book.title}"></button> 
</form> 


O problema é que esse formulario nao esta ligado a nenhum bean da 
nossa aplicação. Para resolver isso, em vez de modificar o formulário inteiro 
para usar as tags do JSF, vamos utilizar uma nova funcionalidade que veio 
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com o JSF 2.2. 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmlns: pt="http://xmlns.jcp.org/jsf/passthrough" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns: jsf="http://xmlns.jcp.org/jsf"> 


<form jsf:id="form" method="post" class="container"> 
<ul id="variants" class="clearfix"> 
<li class="buy-option"> 
<input type="radio" name="id" 
class="variant-radio" 
id="product-variant-#{productDetailBean 
.book.id}" 

value="#{productDetailBean.book.id}" 


checked="checked"/> 


<label class="variant-label" 
for="product-variant-#{productDetailBean 
.book.id}"> 
E-book + Impresso 
</label> 


<small class="compare-at-price"> 
R$ #{productDetailBean.book.price}</small> 
<p class="Variant-price"> 
R$ #{productDetailBean.book.price}</p> 
Ra 
</ul> 


<button type="submit" 
jsf:action="#{shoppingCartBean 
. add (productDetailBean.id)}" 
class="submit-image icon-basket-alt" 
title="#{productDetailBean.book.title}"></button> 
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</form> 


Perceba que usamos um novo namespace, o xmins: jsf="http://xmlns. 
jcp.org/jsf\T1\textquotedbl{}, que importa para a nossa página o recurso do Pass 
Through Elements. Estamos usando o prefixo jsf para referenciá-lo. Este 
recurso nos permite marcar alguns elementos que normalmente seriam sim- 
ples componentes do HTML, como componentes que devem ser gerenciados 
pelo JSF. 


<form jsf:id="form" method="post" class="container"> 


Só de usar um atributo prefixado com jsf já indicamos para o fra- 
mework que ele deve interpretar esse elemento como um componente geren- 
ciado. A parte bem interessante é que o JSF já sabe relacionar vários elementos 
do HTML com seus componentes do servidor. Por exemplo, um formulário 
já é associado com a classe HtmlForm. Usamos a mesma técnica quando 
usamos o botão dentro do formulário. 


<button type="submit" 
jsf :action="#{shoppingCartBean.add(productDetailBean 
«book. id) }" 
class="submit-image icon-basket-alt" 
title="#{productDetailBean.book.title}"></button> 


Usamos o atributo action em um elemento do tipo button, e isso só 
faz sentido porque estamos usando o prefixo jsf. Perceba que passamos 
como argumento justamente a referência para o método que deve ser cha- 
mado no nosso bean responsável por adicionar produtos no carrinho. 

Este recurso veio para fechar uma lacuna importante que existia em apli- 
cações escritas com o JSF. Muitos programadores reclamavam que não tinham 
controle sobre o HTML gerado, o que, a partir desta última versão, deixou de 
ser verdade. Você agora pode montar uma página inteira com HT'ML puro e 


só gerenciar os componentes que você realmente precisa. 
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Lógica para adicionar os produtos no carrinho 


O atributo action do nosso botão está apontando para o método add 
do bean ShoppingCartBean. Vamos dar uma olhada em como está o 
código referente a esta parte do sistema. 


package br.com.casadocodigo. loja.managedbeans.site; 
//imports 


@Model 
public class ShoppingCartBean { 


@Inject 

private ShoppingCart shoppingCart ; 
@Inject 

private BookDAO bookDAO; 


public String add(Integer id){ 
Book book = bookDAO.findById(id) ; 
Shoppingltem item = new ShoppingItem(book) ; 
shoppingCart .add(item) ; 
return "/site/carrinho?faces-redirect=true"; 


public String remove(Integer id){ 
Book book = bookDAO.findById(id) ; 
ShoppingItem item = new ShoppingItem(book) ; 
shoppingCart .remove (item) ; 
return "/site/carrinho?faces-redirect=true"; 


O código em si não tem nada de novo. Apenas usamos outra classe com 
o objetivo de manter os produtos adicionados ao nosso carrinho. Vamos dar 
uma olhada nela: 


package br.com.casadocodigo.loja.models; 
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public class ShoppingCart implements Serializablef{ 


/ xx 
* 
*/ 


private static final long serialVersionUID = 


private Map<ShoppingItem, Integer> items = 
new LinkedHashMap<ShoppingItem, Integer>(); 


public void add(ShoppingItem item) { 
items.put(item, getQuantity(item) + 1); 


public Integer getQuantity(ShoppingItem item) { 
if (!items.containsKey(item)) 1 
items.put(item, 0); 
} 


return items.get (item) ; 


public Integer getQuantity( { 
return items.values() .stream() 
.reduce(0, (next, accumulator) -> next 
+ accumulator) ; 


public Collection<ShoppingItem> getList() { 
return new ArrayList<>(items.keySet()); 


public BigDecimal getTotal(ShoppingItem item) { 
return item.getTotal(getQuantity (item) ); 


public BigDecimal getTotal(){ 
BigDecimal total = BigDecimal. ZERO; 


for(ShoppingItem item : items.keySet()){ 
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total = total .add(getTotal (item)); 
} 


return total; 


public void remove(ShoppingItem shoppingItem) { 
items. remove (shoppingItem) ; 


public boolean isEmpty() { 
return items.isEmpty(); 


} 


Além dessa classe, também precisamos da classe ShoppingItem. 
package br.com.casadocodigo.loja.models; 
//imports 
public class ShoppingItem { 

private Book book; 

// apenas para ficar mais facil de gerar 

// o hashcode e equals 

private Integer bookId; 

public ShoppingItem(Book book) { 


this.book = book; 
this.bookId = book.getId(); 


public Book getBook() { 
return book; 


public BigDecimal getPrice() { 
return book.getPrice(); 
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public Integer getBookId() { 
return bookId; 


public BigDecimal getTotal (Integer quantity) { 
return getPrice() .multiply(mew BigDecimal (quantity) ); 


@Override 
public int hashCode() { 
final int prime = 31; 
int result = 1; 
result = prime * result + ((bookId == null) ? 0: 
bookId.hashCode()) ; 
return result; 


@Override 
public boolean equals(Object obj) f{ 
if (this == obj) 
return true; 
if (obj == null) 
return false; 
if (getClass() != obj.getClass()) 
return false; 
ShoppingItem other = (ShoppingItem) obj; 
if (bookId == null) { 
if (other.bookId != null) 
return false; 
} else if (!bookId.equals (other .bookId)) 
return false; 
return true; 


Os códigos completos dessas classes podem ser encontrados em http:// 
bit.ly/carrinho-casadocodigo. 
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O leitor mais atento deve ter percebido que, após adicionar um produto 
no carrinho, fazemos um redirect para uma tela cuja responsabilidade é jus- 
tamente exibir todos os itens adicionados. 


@Model 
public class ShoppingCartBean { 


@Inject 

private ShoppingCart shoppingCart ; 
@Inject 

private BookDAO bookDAO; 


public String add(Integer id){ 
Book book = bookDAO.findById(id) ; 
ShoppingItem item = new ShoppingItem(book) ; 
shoppingCart .add(item) ; 
return "/site/carrinho?faces-redirect=true"; 


Como ainda não temos esse página pronta, chegou a hora de implemen- 
tarmos. De novo, como ela é um tanto quanto grande, vamos apenas colocar 
os trechos importantes para a nossa leitura. A localização do arquivo deve ser 


site/carrinho.xhtml. 


<form jsf:id="cartForm" method="post"> 
<table id="cart-table"> 


<tbody> 
<ui:repeat var="item" value="#{shoppingCart.list}"> 
<tr> 
<td class="cart-img-col"> 
<img src="#{item.book.coverPath}" 


width="71px" height="100px"/> 
</td> 


153 


7.6. Carrinho de compras e o escopo de sessão Casa do Código 





<td class="item-title">#{item. book.title}</td> 
<td class="numeric-cell">R$ #{item. price}</td> 


<td class="quantity-input-cell"> 
<input type="number" min="0" 
readonly="readonly" 
id="update 
name="upda 
value="#{shoppingCart . getQuantity (item) }"/> 
</td> 


<td class="numeric-cell"> 
R$ #{shoppingCart.getTotal (item) } 
</td> 


<td class="remove-item"> 
<a jsf:action="#{shoppingCartBean 
. remove (item. bookId) }"> 
<img src="..." alt="Excluir" title="Excluir"/> 
</a></td> 
</tr> 
</ui:repeat> 


</tbody> 
<tfoot> 
<tr> 
<td colspan="3"><input type="submit" class="checkout" 
name="checkout" value="Finalizar compra " 
id="checkout"/> 
</td> 
<td class="quantity-input-cell"><input type="submit" 
class="update-cart" name="update" value=""/> 
</td> 
<td class="numeric-cell">R$ #{shoppingCart .total}</td> 
<td></td> 
</tr> 
</tfoot> 
</table> 
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</form> 


Montamos novamente um HTML limpo, e só adicionamos alguns atribu- 
tos do JSF para transformar alguns elementos em componentes gerenciados 
pelo framework. Um detalhe interessante foi que usamos a variável de nome 
shoppingCart, fazendo clara referência à nossa classe ShoppingCart. 


Você deve estar se perguntando: quer dizer que, independente da classe que 





eu crie, os objetos criados a partir dela estarão disponíveis via Expression 
Language? 

Caso isso fosse verdade, nossos DAOs que são instanciados via CDI es- 
tariam disponíveis na página e teríamos uma quebra de camadas muito peri- 
gosa. Para controlar quem deve ficar disponível ou não, podemos usar a an- 
notation @Named. Além disso, ainda precisamos manter esse objeto vivo du- 
rante vários requests do mesmo usuário, contexto também conhecido como 
Session. Precisamos manter o objeto na session, uma vez que nosso usuário 
pode adicionar vários itens no carrinho. 


package br.com.casadocodigo.loja.models; 
//outros imports 


import javax.enterprise.context.SessionScoped; 
import javax.inject.Named; 


@Named 
@SessionScoped 
public class ShoppingCart implements Serializablef{ 


Implementamos Serializable apenas para deixar claro que o estado 
de um objeto desta classe pode ser persistido. Agora nosso usuario ja pode 
adicionar os itens no carrinho e visualizar a lista de produtos que vão ser com- 
prados. 


155 


7.7. Conclusão Casa do Cédigo 





7.7 CONCLUSÃO 


Neste capítulo, implementamos várias funcionalidades da Casa do Código. 
Passamos por algumas dificuldades que foram importantes, já que nos re- 
velaram novas técnicas. Por exemplo, usamos o Pass Through Element 
para manter nosso HTML fiel ao site e só adicionar na árvore do JSF al- 
guns elementos. Além disso, também trabalhamos com a especificação 
dos EJBs, pois usamos a annotation Stateful para conseguir manter um 





EntityManager estendido. 

Minha dica é que você respire um pouco, tente implementar ou digerir 
tudo o que foi exibido até aqui e aí, depois, você continua a leitura. Ainda 
tem muito coisa boa por vir. Já no próximo capítulo vamos nos integrar com 


outro sistema e trabalhar com execuções de códigos assíncronos. 


156 


CAPITULO 8 


Fechamento da compra e 
processamento assincrono 


No capitulo anterior, começamos a implementar o processo de fechamento 
de compra da loja da Casa do Código, e já conseguimos concluir a parte de 
adicionar os itens em um carrinho de compras. Agora, precisamos realmente 
finalizar um novo pedido dentro da loja. 


8.1 IMPLEMENTANDO A TELA DE FINALIZAÇÃO 


A versão de tela de finalização de compra que vamos implementar deve ficar 
próxima da figura a seguir: 


8.1. Implementando a tela de finalização Casa do Cédigo 





Sobrenome 
Resumo do pedido 


CPF/CNPJ 


* spring MVC: Domine o principal RS 69,90 


frames Java x 
Endereço (com número) ramework web Java 





000000 


Casa, apto. etc 
Possu um código de desconto? inaira-o aqu 


Cidade 
País t Em =- 


Estado 


R$ 69,90 


Talatone 


Fig. 8.1: Tela de checkout da Casa do Código 


Primeiro, precisamos alterar um pouco nosso código da tela do carrinho 
para adicionar um link que nos leve para o endereço de finalização de compra. 


<tfoot> 
<tr> 
<td colspan="3"> 
<a href="$(request.contextPath)/site/checkout. xhtml" 
id="checkout" class="checkout">Finalizar compra 
</a></td> 


</tr> 
</tfoot> 
Simplesmente adicionamos um link que levará o usuário para a tela de 
checkout. Por sinal, essa vai ser mais uma página na qual usaremos bastante 
o novo recurso do Pass Through Elements. 
Basicamente, vamos ter o HTML já definido pela Casa do Código, e 
apenas serão modificados os elementos que devem ser gerenciados pelo 


JSF. O arquivo responsável por montar a tela de checkout deve ficar em 
site/checkout .xhtml. 
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Como ja vem sendo feito, vamos apenas analisar as partes importan- 
tes do código. O arquivo completo pode ser encontrado em http://bit.ly/ 
checkout-casadocodigo. 


<form accept-charset="UTF-8" jsf:prependId="false" 
class="section__form 
js-shipping-address-with-selector" 
jsf:id="checkoutUserForm" method="post" 
<div style="display:none"></div> 


<div class="fieldset" 
data-email-check=’#checkout_email_suggestion’> 
<div class="field field--required"> 
<label for="checkout_email">E-mail</label> 
<input autocapitalize="off" 
autocomplete="shipping email" 
jsf:id="email" data-autofocus="true" 
jsf : value="#{checkoutBean.systemUser.email}" 
placeholder="E-mail" size="30" 
spellcheck="false" 
type="email"/> 
</div> 


</div> 
<h5>Endereço de entrega</h5> 


<div class="fieldset" id="shipping-address" 
data-shipping-address=""> 
<div class="field field--optional"> 
<label for= 
"checkout shipping address first name'> 
</label> 
Nome 
<input autocomplete="shipping given-name" 
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jsf:id="name" 

jsf: value="#{checkoutBean.systemUser 
.firstName}" 

placeholder="Nome" size="30" 

type="text"/> 


</div> 
<div class="field field--required"> 
<label for= 
"checkout_shipping_address_last_name"> 
Sobrenome</label> 


<input autocomplete="shipping family-name" 
jsf:id="lastName" 
jsf:value='g(checkoutBean. systemUser 
.lastName}" 
placeholder="Sobrenome" size="30" 
type="text"/> 
</div> 


<div class="field field--required"> 
<label for= 
"checkout_shipping_address_company"> 
CPF/CNPJ 
</label> 
<input autocomplete="shipping organization" 
jsf:id="socialId" 
jsf: value="#{checkoutBean.systemUser 
.socialId}" 
placeholder="999.999.999-99" size="30" 
type="text"> 
</div> 


<div class="field field--required" 
data-country-section="1"> 
<label for= 
"checkout shipping address country'> 


País 
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</label> 
<select 
jsf : value="#{checkoutBean.systemUser 
.country}" 
jsf:id="country" size="1"> 
<f:selectItem itemValue="" 
itemLabel="Escolha o pais"/> 
<f:selectItem itemValue="Portugal" 
itemLabel="Portugal"/> 
<f:selectItem itemValue="Brasil" 
itemLabel="Brasil"/> 
<f:selectItem itemValue="Africa do Sul" 
itemLabel="Africa do Sul"/> 
<f:selectItem itemValue="Argentina" 
itemLabel="Argentina"/> 
<f:selectItem itemValue="Colombia" 
itemLabel="Colombia"/> 
</select> 
</div> 


É um formulário com muitos campos, e aqui só exibimos alguns. A parte 
interessante é que conseguimos manter o HTML original, e apenas adiciona- 
mos alguns atributos específicos do JSF para que o framework entenda que os 
inputs e o formulário em si devam ser tratados como componentes. Um que 
nos deu um pouco mais de trabalho foio select. 


<select jsf:value="t(checkoutBean. systemUser.country)" 
jsf:id="country" size="1"> 
<f:selectItem itemValue="" itemLabel="Escolha o pais"/> 
<f:selectItem itemValue="Portugal" itemLabel="Portugal"/> 
<f:selectItem itemValue="Brasil" itemLabel="Brasil"/> 
<f:selectItem itemValue="Africa do Sul" 
itemLabel="Africa do Sul"/> 
<f:selectItem itemValue="Argentina" itemLabel="Argentina"/> 
<f:selectItem itemValue="Colombia" itemLabel="Colombia"/> 
</select> 


O JSF sabe apenas que uma tag select, marcada com um atributo es- 
pecial, deve virar um componente do tipo HtmlSelectOneListBox, mas 
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não tem ideia do que fazer com os elementos opt ion que, pensando apenas 
em HTML, deveriam vir dentro de um select. Por conta dessa limitação, 
somos obrigados a usar a tag select Item, o que realmente não impacta 
muito. 

Outro detalhe bem interessante é que a usamos como filha de um 
select, justamente para deixar claro que o fato de marcar um elemento 
HTML com um atributo JSF realmente o faz ser gerenciado e entrar na ár- 
vore de componentes. 


8.2 (GRAVANDO AS INFORMAÇÕES DO USUÁRIO 


O leitor mais atento já deve ter percebido o uso de um novo bean para lidar 
com a finalização do pedido. O value de todos os inputs estão apontando 
para #{checkoutBean. ..}, que é justamente esse novo bean. A primeira 
tarefa que vamos tratar é a de gravar as informações do novo comprador. 

Apenas para refrescar sua memória, vamos olhar um dos inputs do for- 
mulário mais uma vez: 


<input autocapitalize="0ff" autocomplete="shipping email" 
jsf:id="email" data-autofocus="true" 
jsf :value="#{checkoutBean.systemUser.email}" 
placeholder="E-mail" size="30" spellcheck="false" 
type="email"/> 


<input class="btn" name="commit" 
jsf :action="#{checkoutBean. checkout () +" 
type="submit" value="Continuar" /> 


Perceba que ele esta associado aos métodos de acesso que retornam um 
objeto que representa um usuário. Além disso, o botão de finalização deve 
fazer uso do método checkout na mesma classe. Vamos dar uma olhada 
para entender um pouco mais do código. 


package br.com.casadocodigo.loja.managedbeans.site; 
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//imports 


@Model 
public class CheckoutBean { 


private SystemUser systemUser = new SystemUser(); 
@Inject 

private SystemUserDAO systemUserDAO; 

@Inject 

private ShoppingCart cart; 


public SystemUser getSystemUser() { 


return systemUser; 


public void setSystemUser (SystemUser systemUser) { 
this.systemUser = systemUser; 


@Transactional 
public void checkout() throws IOException { 
systemUserDA0.save(systemUser) ; 


//vamos também gravar a compra 
//aprovar com um sistema externo 


A classe éum bean normal, nada que não tenhamos trabalhado até agora. 
Para que tudo funcione, precisamos apenas implementar a parte relativa ao 
usuário. Começaremos pela classe SystemUser. 


package br.com.casadocodigo.loja.models; 
//imports 


CEntity 
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public class SystemUser { 


@Id 
@GeneratedValue(strategy = GenerationType. IDENTITY) 
private Integer id; 
CEmail 

@NotBlank 

@Column (unique=true) 
private String email; 
@NotBlank 

private String firstName; 
@NotBlank 

private String lastName; 
@NotBlank 

@Column (unique=true) 
private String sociallId; 
NotBlank 

rivate String address; 
NotBlank 

rivate String city; 
NotBlank 

ivate String state; 
NotBlank 

rivate String postalCode; 
NotBlank 

rivate String phone; 
NotBlank 

private String country; 


K 








@ 
P 
@ 
P 
@ 
P 
@ 
P 
@ 
P 
@ 


private String password; 
//metodos de acesso 


E simplesmente uma classe mapeada com annotations da JPA e da Bean 
Validation. Para fechar, é necessário que tenhamos o DAO responsável por 
gravar um novo usuário no banco de dados. 


package br.com.casadocodigo.loja.daos; 


//imports 
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public class SystemUserDAO { 


@PersistenceContext 
private EntityManager entityManager; 


public void save(SystemUser systemUser) { 
entityManager.persist (systemUser) ; 


Isso já é suficiente para gravarmos o usuário que está comprando um novo 
produto. Poderíamos ter verificado, por exemplo, se o e-mail já existe para 
não cadastrar de novo. Fica como desafio para o leitor incrementar ainda 
mais a aplicação. 


Ajuda extra com o OmniFaces 


Por conta da integração do JSF com a Bean Validation, nosso formulário 
inclusive já está sendo validado. Basta adicionarmos atag message embaixo 
de cada input para exibirmos as mensagens de erro. 


<input autocapitalize="0ff" autocomplete="shipping email" 
jsf:id="email" data-autofocus="true" 
jsf: value="#{checkoutBean.systemUser.email}" 
placeholder="E-mail" size="30" spellcheck="false" 
type="email"/> 


<p class="field_error-message"><h:message for="email"/> 
</p> 


Esse código até funciona e não influencia diretamente no layout da apli- 
cação, mas de todo jeito estamos exibindo o <p> sempre em vez de só exibir 
quando realmente existir um problema. Para contornarmos isso, teríamos de 
verificar se alguma mensagem foi adicionada ou não. 

Com a intenção de ajudar o desenvolvedor que utiliza o JSF no dia a dia, 
Bauke Scholtz criou uma biblioteca chamada OmniFaces. A ideia desse pro- 
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jeto é oferecer classes e tags extras que realmente possam ajudar enquanto 
estamos desenvolvendo uma aplicação baseada em JSF. 


Segue uma pequena lista de utilidades fornecidas pelo OmniFaces: 


e Novos validadores; 
e Mais facilidades com AJAX; 
e Formatadores mais elaborados; 


e Novos componentes. 


Para o nosso caso, vamos usar uma versão diferente da tag messages, 
uma extensão provida pelo OmniFaces que se aplica muito bem para a nossa 
situação. 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmins:pt="http://xmins.jcp.org/jsf/passthrough" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns: jsf="http://xmlns.jcp.org/jsf" 
xmlns:o="http://omnifaces.org/ui"> 


<input autocapitalize="0ff" autocomplete="shipping email" 
jsf:id="email" data-autofocus="true" 
jsf: value="#{checkoutBean.systemUser.email}" 
placeholder="E-mail" size="30" spellcheck="false" 
type="email"/> 


<o:messages for="email" var="message"> 
<p class="field_error-message"> 
#{message.summary}</p> 
</o:messages> 


Tivemos de importar o namespace http://omnifaces.org/ui. Perceba que 
agora usamos a tag messages associada ao prefixo o:. Essa tag só exibe o 
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conteúdo entre ela caso exista alguma mensagem associada ao componente 
referenciado pelo atributo for. 

Não precisamos colocar todo o código do formulário aqui, use a mesma 
tag para exibir as mensagens de erros dos outros campos. Fique apenas atento 
ao id que você vai utilizar no atributo for. 

Precisamos adicionar o OmniFaces ao nosso projeto. Para isso, basta que 
seja adicionada uma nova dependência no nosso arquivo pom.xml. 


<project ....> 
<dependencies> 


<!-- omni --> 


<dependency> 
<groupId>org.omnifaces</groupId> 
<artifactId>omnifaces</artifactId> 
<version>2.1</version> 
</dependency> 


</dependencies> 


</project> 


Tente não confundir o OmniFaces com uma biblioteca, como o Prime- 
Faces. Enquanto o último tenta trazer novos componentes de layout para o 
nosso código, o primeiro foca em classes e tags utilitárias. 


8.3 VALIDAÇÃO SELETIVA COM A BEANVALIDATION 


Para representar o usuário, foi usada a classe SystemUser. Um possível 
problema que podemos ter é que, mais à frente, quando adicionarmos a parte 
de segurança na aplicação, teremos dois tipos de usuários: um com todas as 
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informações preenchidas, representando tipicamente um comprador da Casa 
do Código; e outro que só precisará do e-mail e da senha, já que será um 
usuário com papel de administrador. 

Analisando a classe SystemUser, percebemos que adicionamos as re- 
gras de validações em quase todos os atributos. 


CEntity 
public class SystemUser { 


@Id 
@GeneratedValue(strategy = GenerationType. IDENTITY) 
private Integer id; 
@Email 

@NotBlank 

@Column (unique=true) 
private String email; 
@NotBlank 

private String firstName; 
@NotBlank 

private String lastName; 
@NotBlank 

@Column (unique=true) 
private String sociallId; 
NotBlank 

rivate String address; 
NotBlank 

rivate String city; 
NotBlank 

ivate String state; 
NotBlank 

rivate String postalCode; 
NotBlank 

rivate String phone; 
NotBlank 

private String country; 


K 








@ 
P 
@ 
P 
@ 
P 
@ 
P 
@ 
P 
@ 


private String password; 


E quando tivermos de cadastrar um novo usuário que é administrador? 
Como vamos fazer para ensinar a implementação da JPA que ela não deve 
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validar todas essas informações? 
Mantendo as annotations e gerando as tabelas por meio do próprio Hiber- 
nate, inclusive as colunas do banco são geradas não aceitando valores nulos. 
Pensando justamente neste tipo de situação, a Bean Validation já previu 
que você pode ter grupos de validação. 


CEntity 
public class SystemUser { 


@Id 

@GeneratedValue(strategy = GenerationType. IDENTITY) 
private Integer id; 

CEmail 

@NotBlank 

@Column(unique=true) 

private String email; 

NotBlank (groups=BuyerGroup.class) 
rivate String firstName; 

NotBlank (groups=BuyerGroup.class) 
rivate String lastName; 

NotBlank (groups=BuyerGroup.class) 
rivate String socialld; 

NotBlank (groups=BuyerGroup.class) 
rivate String address; 


rivate String city; 

NotBlank (groups=BuyerGroup.class) 
rivate String state; 

NotBlank (groups=BuyerGroup.class) 
rivate String postalCode; 
NotBlank (groups=BuyerGroup.class) 
rivate String phone; 








@ 
P 
@ 
P 
@ 
P 
@ 
P 
@NotBlank (groups=BuyerGroup.class) 
P 
@ 
P 
@ 
P 
@ 
P 
@ 


NotBlank (groups=BuyerGroup.class) 
private String country; 
private String password; 


O atributo groups permite que vocé passe a referéncia para uma 
interface que define o grupo que pertence a alguma validação. Perceba 
que deixamos apenas os atributos email e password sem grupo algum. A 
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interface que define o grupo não precisa ter método algum, é a típica interface 
de marcação. 


package br.com.casadocodigo.loja.models.validation.groups; 


public interface BuyerGroup { 


Como o JSF já é integrado com a Bean Validation, podemos dizer que cada 
input do formulário deve ter sua validação associada a um grupo específico. 


Vamos analisar novamente o arquivo checkout . xhtml: 


<form accept-charset="UTF-8" jsf:prependId="false" 
class="section__form js-shipping-address-with-selector" 
jsf:id="checkoutUserForm" method="post"> 
<div style="display:none"></div> 


<div class="fieldset" 
data-email-check=’#checkout_email_suggestion’> 
<div class="field field--required"> 
<label for="checkout_email">E-mail</label> 
<input autocapitalize="o0ff" 
autocomplete="shipping email" 
jsf:id="email" data-autofocus="true" 
jsf: value="#{checkoutBean.systemUser.email}" 
placeholder="E-mail" size="30" 
spellcheck="false" type="email"> 


<f:validateBean 
validationGroups="br.com.casadocodigo.loja 
.models.validation.groups.BuyerGroup"/> 
</input> 
</div> 


</div> 
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<h5>Endereço de entrega</h5> 


<div class="fieldset" id="shipping-address" 
data-shipping-address=""> 
<div class="field field--optional"> 

<label for= 
"checkout shipping address first name'> 
Nome 

</label> 

<input autocomplete="shipping given-name" 
jsf:id="name" 
jsf: value="#{checkoutBean. systemUser.firstName}" 
placeholder="Nome" size="30" type="text"> 


<f: validateBean 
validationGroups="br.com.casadocodigo.loja 
.models.validation.groups.BuyerGroup"/> 


</input> 


</div> 
<div class="field field--required"> 
<label for="checkout shipping address last name"> 
Sobrenome</label> 
<input autocomplete="shipping family-name" 
jsf:id="lastName" 
jsf: value="#{checkoutBean.systemUser.lastName}" 
placeholder="Sobrenome" size="30" type="text"> 


<f: validateBean 
validationGroups="br.com.casadocodigo.loja 
.models.validation.groups.BuyerGroup"/> 
</input> 
</div> 


<div class="field field--required"> 
<label for="checkout. shipping address. company"> 
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CPF/CNPJ 

</label> 

<input autocomplete="shipping organization" 
jsf:id="socialId" 
jsf: value="#{checkoutBean.systemUser 

.sociallId}" 

placeholder="999.999.999-99" size="30" 
type="text"> 


<f:validateBean 
validationGroups="br.com.casadocodigo.loja 
.models.validation.groups.BuyerGroup"/> 
</input> 
</div> 


<div class="field field--required" 
data-country-section="1"> 
<label for="checkout. shipping address country'> 
País 
</label> 
<select 
jsf: value="#{checkoutBean.systemUser.country}" 
jsf:id="country" size="1"> 
<f:validateBean 
validationGroups="br.com.casadocodigo.loja 
.models.validation.groups.BuyerGroup"/> 
<f:selectItem itemValue="" 
itemLabel="Escolha o pais"/> 
<f:selectItem itemValue="Portugal" 
itemLabel="Portugal"/> 
<f:selectItem itemValue="Brasil" 
itemLabel="Brasil"/> 
<f:selectItem itemValue="Africa do Sul" 
itemLabel="Africa do Sul"/> 
<f:selectItem itemValue="Argentina" 
itemLabel="Argentina"/> 
<f:selectItem itemValue="Colombia" 
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itemLabel="Colombia"/> 
</select> 
</div> 


Devemos fazer isso para todos os inputs que devam ser validados quando 
uma compra na loja estiver acontecendo. De novo, estamos usando o po- 
der do Pass Through Elements. Transformamos um simples input em um 
componente do JSF e, com isso, ganhamos o direito de associar outros com- 
ponentes do framework a esse elemento. Os grupos de validação são previstos 
na especificação; não tenha medo de usá-los. 


8.4 SALVANDO AS INFORMAÇÕES DO CHECKOUT 


Já estamos salvando as informações do usuário quando ele clica no botão para 
fechar o pedido. O próximo passo é armazenar todas as informações da com- 
pra em si. 


@Model 
OPath ("payment") 
public class CheckoutBean { 


private SystemUser systemUser = new SystemUser(); 
@Inject 

private SystemUserDAO systemUserDAO; 

@Inject 

private CheckoutDAO checkoutDAO; 

@Inject 

private ShoppingCart cart; 


public SystemUser getSystemUser() { 
return systemUser; 


public void setSystemUser (SystemUser systemUser) { 
this.systemUser = systemUser; 
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@Transactional 
public void checkout() throws IOException { 
systemUserDA0.save(systemUser) ; 


Checkout checkout = new Checkout (systemUser, cart); 
checkoutDAO. save (checkout); 


Para que o código anterior compile, é necessário que seja criada a classe 
Checkout, além do DAO. O código do DAO não tem nada novo, já que sim- 
plesmente precisamos salvar o objeto. 


package br.com.casadocodigo.loja.daos; 
public class CheckoutDAO { 


@PersistenceContext 
private EntityManager entityManager; 


public void save(Checkout checkout) 1 
entityManager .persist (checkout) ; 


Já o código da classe Checkout precisa de um certo momento de refle- 


xão. Precisamos gravar as seguintes informações: 


e Usuário associado à compra; 
e Valor total do carrinho; 


e Os produtos associados à compra. 


Uma ideia inicial seria, então, ter classes parecidas com as seguintes: 


CEntity 
public class Checkout { 
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@Id @GeneratedValue (strategy=GenerationType. IDENTITY) 
private Integer id; 

@ManyToOne 

private SystemUser buyer; 

private BigDecimal value; 

private List<Item> items = new ArrayList<>(); 


@Entity 
public class FinalShoppingItem { 


@Id @GeneratedValue (strategy=GenerationType. IDENTITY) 
private Integer id; 

@ManyToOne 

private Book book; 

private int quantity; 

private BigDeciamal currentPrice; 


Esse modelo até funciona, mas para o nosso caso é suficiente guardar uma 
representação mais simples do carrinho, apenas para consultas futuras. Então, 
em vez de modelar desse jeito, podemos fazer o seguinte: 


CEntity 
public class Checkout 1 


@Id @GeneratedValue (strategy=GenerationType. IDENTITY) 
private Integer id; 

@ManyToOne 

private SystemUser buyer; 

private BigDecimal value; 

private String jsonCart; 


//construtor para ser usado pelos frameworks 
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protected Checkout() { 


public Checkout (SystemUser user, ShoppingCart cart) { 
this.buyer = user; 
this.value = cart.getTotal(); 
this.jsonCart = cart.toJson(); 


A ideia é guardarmos as informações do carrinho como um JSON, um 
formato muito conhecido de representação de dados. Inclusive, os bancos 
mais conhecidos já suportam que dados sejam armazenados neste formato. 
Acesse o link http://bit.ly/json-mysql e leia um pouco mais. 


Adicionamos o método toJson dentro da classe ShoppingCart. 


public class ShoppingCart { 


public String toJson() { 
//como vamos gerar o JSON? 


Usando a nova especificação de geração de JSON 


A JSR 353 (https://www.jcp.org/en/jsr/detail?id=353) define uma das no- 
vas especificações do Java EE 7, a Java API for JSON Processing. Isso quer 
dizer que você já tem suporte à geração de JSON dentro de qualquer servidor 
que implemente a última versão da spec. Isso se encaixa perfeitamente para 
as nossas necessidades! 


public String toJson() { 
JsonArrayBuilder itens = Json.createArrayBuilder () ; 
for (ShoppingItem item : getList()) 1 
itens.add(Json.createObjectBuilder () 
.add("title", item.getBook() .getTitle()) 
.add("price", item.getBook() .getPrice()) 
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.add("quantity", getQuantity (item). intValue()) 
.add("sum", getTotal (item))); 


} 
return itens.build() .toString(); 


Perceba que a montagem do JSON é um pouco manual, mas, em com- 
pensação, nos permite de forma clara decidir exatamente o que precisamos 
que seja gerado. Vamos dar uma olhada em cada das classes envolvidas. 

A classe Json é seu ponto de partida. Ela possui os métodos necessários 
para o início da criação do seu JSON. Por exemplo, no nosso caso, foi preciso 
pedir pela construção de um Array, pois precisamos guardar todos os itens 
do carrinho. Além disso, de dentro do loop, é necessário criar uma repre- 
sentação para cada item do nosso carrinho. Quando queremos criar apenas 
um objeto JSON, usamos o método createObjectBuilder e vamos adi- 
cionando as informações necessárias. O resultado gerado é parecido com o 


seguinte: 
L 
{ 
"title": "javaee", 
"price": 100, 
"quantity": 1, 
"sum": 100 
>, 
{ 
"title": "spring mvc", 
"price": 100, 
"quantity": 1, 
"sum": 100 
} 
] 


Estamos quase lá. O nosso pedido já é gerado e associado com o novo 
comprador. Agora vamos, por enquanto, para a parte final do nosso processo. 
Precisamos validar o valor da nossa compra em um sistema externo! 
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JSON-B 


No Java EE 8 será disponibilizado a especificação JSON-B (Java API 
for JSON Binding), que vai nos possibilitar transformar objetos em JSON 
e sair de JSON para objetos, de forma automatica. 











8.5 INTEGRANDO COM OUTRA APLICAÇÃO 


Para a aplicação ficar ainda mais parecida com uma da vida real, vamos ter de 
nos integrar com um sistema externo para validar o valor final da compra. 

A lógica é simples: só aceitamos pagamentos de até R$500,00 reais. So- 
mos obrigados a passar os dados usando o JSON, e vamos usar o HTTP como 
protocolo de integração. 

Caso o valor tenha seguido a regra, é retornado o status 201, que indica 
que um novo recurso foi criado, neste caso, o pagamento. Por outro lado, se 
tiver sido passado um valor maior que 500, é retornado o status 400, o que 
indica que a requisição possui dados inválidos. 

Caso você queira efetuar um teste e esteja usando Linux ou Mac, basta 


executar um curl. 


curl --header "Content-type: application/json" --request POST 
--data ’{"value": 600}? 
http: //book-payment . herokuapp. com/payment 


Um outro jeito de verificar é usando um plugin do Chrome, o Postman. 


JAX-RS client 


Vamos precisar de uma biblioteca que nos ajude a realizar a requisição 
HTTP, para que nossa integração funcione. Para a nossa sorte, na última ver- 
são do Java EE, foi adicionado o suporte a este tipo de cenário na especificação 
JAX-RS. Vamos lidar mais diretamente com essa especificação em um capí- 
tulo mais para a frente, onde teremos que expor os dados do nosso sistema 
em outros formatos. 

Para não perder muito tempo, vamos ver como ficaria o código final da 
finalização do checkout. 
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@Model 
public class CheckoutBean { 


@Transactional 
public void checkout() throws IOException { 
systemUserDA0.save(systemUser) ; 


Checkout checkout = new Checkout (systemUser, cart) ; 
checkoutDAO.save(checkout) ; 


//cédigo de integração 
Client client = ClientBuilder .newClient (); 
PaymentData paymentData = new PaymentData(total); 
String uriToPay = 

"http: //book-payment .herokuapp.com/payment"; 


Entity<PaymentData> json = Entity.json(paymentData) ; 


WebTarget target = client.target (uriToPay) ; 
Builder request = target.request(); 
request.post(json, String.class) ; 


Respire um pouco e vamos pensar sobre o trecho de código que acabamos 


de escrever. 


1) Criamos o objeto do tipo Client para fazer a requisição; 





2) Geramos o JSON de um objeto por meio da classe Entity; 
3) Definimos o endereço da requisição por meio do método target; 


4) Construímos a requisição em si, com o método request; 


5) Disparamos um post com o JSON e informamos que simplesmente es- 


peramos um String de resposta. 


8.5. Integrando com outra aplicação Casa do Código 





A API de fazer requisições ficou com um design bem interessante. Os 
passos são bem marcados e um depende do outro. O trecho final, em que 
montamos a requisição em si, poderia ter sido escrito de uma forma mais 
sucinta. 


client.target (uriToPay) .request() .post(json, String.class) ; 


a 


Outro detalhe que pode chamar a atenção é a utilização da classe 
PaymentData. Qual o motivo de necessitarmos dela? O sistema de paga- 
mento com o qual estamos realizando a integração pede que o formato do 
dado passado seja o seguinte: 


{"value": 600} 


E como se fosse um Map, precisamos de uma chave chamada value 
associada a um valor qualquer. Caso passemos 0 BigDecimal direto, qual 
seria o nome dessa chave? É justamente por isso que precisamos criar uma 
classe. 


package br.com.casadocodigo.loja.models; 
import java.math.BigDecimal; 
public class PaymentData { 

private BigDecimal value; 


public PaymentData() { 
} 


public PaymentData(BigDecimal value) { 
this.value = value; 
public BigDecimal getValue() { 


return value; 
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Repare que temos um atributo que se chama exatamente value, justa- 
mente para que 0 JSON seja gerado com as chaves corretas. 

Outro ponto em que precisamos ter atenção é para a semântica do código. 
Para uma pessoa que não conhece o sistema, o que esse conjunto de linhas 
quer dizer? 


@Transactional 
public void checkout() throws IOException { 


//código de integração 
Client client = ClientBuilder.newClient(); 
PaymentData paymentData = new PaymentData(total); 
String uriToPay = 

"http: //book-payment .herokuapp.com/payment"; 
Entity<PaymentData> json = Entity.json(paymentData) ; 
WebTarget target = client.target (uriToPay); 
Builder request = target.request(); 
request.post(json, String.class) ; 


O que estamos fazendo é aprovando um pagamento com um sistema ex- 
terno, mas nosso código contém apenas um monte de linhas usando uma API. 
Para melhorar, vamos deixá-lo da seguinte forma. 


@Model 
public class CheckoutBean { 


@Inject 

private PaymentGateway paymentGateway; 
@Transactional 

public void checkout() throws IOException { 


systemUserDA0.save(systemUser) ; 


Checkout checkout = new Checkout (systemUser, cart); 
checkoutDAO.save(checkout) ; 
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paymentGateway.pay (total); 


Agora, basta que a classe Payment Gateway seja criada. 


package br.com.casadocodigo.loja.services; 
import java.math.BigDecimal; 


import javax.ws.rs.client.Client; 
import javax.ws.rs.client.ClientBuilder; 
import javax.ws.rs.client.Entity; 


public class PaymentGateway { 


public PaymentGateway() { 
} 


public void pay(BigDecimal total) { 

Client client = ClientBuilder.newClient(); 
PaymentData paymentData = new PaymentData(total) ; 
String uriToPay = 

"http: //book-payment .herokuapp.com/payment"; 
Entity<PaymentData> json = Entity.json(paymentData) ; 
client .target (uriToPay) .request () 

.post(json, String.class) ; 


182 


Casa do Cédigo Capitulo 8. Fechamento da compra e processamento assincrono 





8.6 EXECUTANDO OPERAÇÕES DEMORADAS ASSIN- 
CRONAMENTE 


Agora que nosso código de integração já funciona, vamos tentar pensar um 
pouco adiante. A Casa do Código é uma empresa de sucesso, o Brasil in- 
teiro compra livros de tecnologia nela. Em certos momentos do ano, como 
na Black Friday, ela libera certas promoções que fazem com que o site fique 
muito movimentado e, com isso, temos muitos usuários concluindo compras 
ao mesmo tempo. Algo similar acontece em todas as outras empresas. 

Não é raro nessas situações de uso intenso que os sistemas fiquem um 
pouco mais lentos, ou até que caiam e fiquem fora do ar por um tempo, o que 
pode gerar um prejuízo grande. Em geral, todos os sistemas têm seus pontos 
de gargalo e, como não poderia ser diferente, nós temos o nosso também. 

Já se perguntou quanto tempo pode levar para a nossa aplicação fazer uma 
requisição para o sistema de pagamento? Caso esse outro sistema demore, o 
que pode acontecer com o nosso site? 

Neste exato momento, o funcionamento é basicamente o seguinte: 
quando uma nova requisição chega ao nosso servidor web, ele faz um tra- 
tamento inicial e delega a responsabilidade para a Servlet configurada, nesse 
caso, a do JSF. A FacesServlet vai descobrir quais beans devem ser aci- 
onados para tratar a requisição, e fazer o trabalho para que isso realmente 
aconteça. 

Todo esse fluxo acontece dentro de uma Thread criada pelo servidor web, 
para que ele possa tratar várias requisições simultaneamente. Essa Thread só 
é liberada quando o método do nosso bean acaba de fazer o trabalho e indica 
para qual endereço devemos ir. 

Esse modelo de trabalho, em que alguém fica esperando o outro acabar 
para aí sim continuar seu trabalho, é conhecido como modelo síncrono. O 
problema desse modelo é que o servidor web tem um número limitado de 
Threads que podem ser criadas e, caso esse número chegue ao limite, as re- 
quisições dos nossos usuários vão começar a ser enfileiradas e podemos ter 
uma lentidão nas aplicações. 

Como já comentamos, em um pico de acesso, podemos sofrer deste pro- 
blema justamente no momento em que precisamos realizar a integração com 
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um sistema externo, no qual não temos nenhum controle sobre o tempo de 
resposta. 

A grande sacada para esse tipo de situação é tentar liberar o servidor para 
atender outras requisições enquanto realizamos a integração com o nosso 
meio de pagamento. É exatamente para isso que, desde a versão 3 da espe- 
cificação de Servlets, você pode criar uma Servlet que consegue trabalhar de 
modo assíncrono! E, para a nossa sorte, o Java EE 7 nos fornece uma abstração 
sobre isso. 

Antes de entrarmos na implementação provida pela especificação, vamos 
pensar no exemplo de código que gostaríamos de ter. 


@Transactional 
public void checkout() throws IOException { 
systemUserDA0.save(systemUser) ; 


Checkout checkout = new Checkout(systemUser, cart); 
checkoutDAO. save(checkout) ; 


new Thread(() -> { 
paymentGateway . pay (checkout .getValue()); 


» .start O; 


Esse seria o jeito mais simples, mas temos um problema principal. Uma 
vez que você disparou a thread, o processamento do request vai acontecer 
normalmente, e não é bem isso que queremos. Precisamos que a resposta 
só seja gerada quando a lógica de aprovar uma nova compra for processada. 
De dentro da nossa thread, necessitamos de algum objeto que nos permita 
notificar ao servidor o exato momento que ele está liberado para devolver a 
resposta para o cliente. 

Infelizmente, a especificação do JSF não foi concebida para tratarmos re- 
quisições dessa maneira. Por conta disso, vamos ter de quebrar nosso pro- 
cesso de checkout em duas etapas. 

De dentro do nosso bean do JSF, vamos apenas gravar os dados no banco 
de dados. Quando essa operação acabar, vamos redirecionar a requisição para 
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outro endereço responsável apenas por aprovar a compra. Daqui a pouco, 


trataremos dessa outra parte do sistema. Agora vamos resolver a parte do JSF. 


@Model 


public class CheckoutBean { 


private SystemUser systemUser = new SystemUser() ; 
@Inject 

private SystemUserDAO systemUserDAO; 

@Inject 

private CheckoutDAO checkoutDAO; 

@Inject 

private ShoppingCart cart; 

@Inject 

private FacesContext facesContext ; 

@Transactional 


public void checkout() throws IOException { 


systemUserDA0.save(systemUser) ; 


Checkout checkout = new Checkout (systemUser, cart) ; 
checkoutDAO.save(checkout) ; 


String contextName = facesContext.getExternalContext () 


. getContextName () ; 


HttpServletResponse response = (HttpServletResponse) 


externalContext .getResponse() ; 


response. setStatus (307) ; 


response. setHeader("Location", "/"+contextNamet"/ 


services/payment?uuid="+checkout.getUuid()); 


Usamos 0 HttpServletResponse para realizar um redirect para um 





endereco que nao tem nada a ver com JSF. Os redirects que usam o parametro 





do faces 


redirect=true, por meio do FacesContext, só podem ser 


feitos para URLs tratadas pelo Servlet do próprio JSF. 
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Um outro ponto a se observar nesse código é o uso do status 307, cujo 
significado é Temporary Redirect. O endereço que vai fazer a parte final da 
integração deve ser acessado via POST, já que não queremos que o navegador 
grave o endereço e possibilite um acesso descuidado de um usuário. 

Esse status serve justamente para informar para o cliente que o próximo 
redirecionamento deve ser feito com o mesmo verbo usado para acessar o 
endereço atual, que no caso foium POST. O header Location indica qual 
endereço o cliente deve acessar para efetuar o redirecionamento. 

Outro detalhe interessante é que passamos um argumento chamado 
uuid. A ideia é sempre gerar um identificador um pouco mais complicado 
para cada pedido, para que nenhum usuário tente alterar a URL e coloque um 
ID de compra válida. Para não termos que lembrar de definir esse uuid o 
tempo inteiro, vamos utilizar um recurso provido pela JPA. 


CEntity 
public class Checkout { 


private String uuid; 


@PrePersist 
public void prePersist Of 
this.uuid = UUID.randomUUID() .toString() ; 


Vocé pode anotar um método da sua entidade com a annotation 
@PrePersist, e ele vai ser invocado logo antes da invocação método 





persist, do EntityManager 

Esses métodos são conhecidos como métodos de callback, e podem ser 
de grande ajuda quando temos lógicas que sempre devem acontecer sob de- 
terminadas circunstâncias. 


Existem outras annotions de callback da JPA: 
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e PreUpdate - o método é executado logo antes de um merge; 
e PostUpdate - o método é executado logo após um merge; 
e PreRemove — o método é executado logo antes de um remove; 


* PostRemove - o método é executado logo após um remove; 





* PostLoad - o método executado logo após um find ou um 


getReference. 


8.7 JAX-RS PARA TODAS AS OUTRAS REQUISICOES 
HTTP 


Até agora estávamos usando o JSF para tratar as requisições web referentes à 
nossa aplicação. Entretanto, como ele não oferece suporte para tratar as mes- 
mas requisições de forma assíncrona, vamos ter de optar por outro pedaço da 
especificação, o JAX-RS. 

O JAX-RS, acrônimo para The Java API for RESTful Web Services, é a es- 
pecificação que nos possibilita participar de integrações puramente baseadas 
no protocolo HT'TP. Ainda vamos explorar mais dessas possibilidades em um 
capítulo especial só para isso, mas nesse momento já necessitamos da espe- 
cificação por conta da sua integração com os contextos assíncronos providos 
pela especificação de Servlets. 

A ideia é que criemos um bean do JAX-RS, também conhecido como 
Resource, para carregar a compra pelo uuid e fazer a integração com o 
sistema externo. 


package br.com.casadocodigo.loja.resources; 


import javax.ws.rs.GET; 

import javax.ws.rs.Path; 

import javax.ws.rs.QueryParam; 
import javax.ws.rs.core.Context; 
import javax.ws.rs.core.Response; 
import javax.ws.rs.core.UriBuilder; 
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@Path ("payment") 
public class PaymentResource { 


@Inject 

private CheckoutDAO checkoutDao; 
@Inject 

private PaymentGateway paymentGateway; 


@POST 

public Response pay(@QueryParam("uuid") String uuid) { 
String contextPath = ctx.getContextPath() ; 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 


BigDecimal total = checkout.getValue(); 
paymentGateway.pay (total); 
URI redirectURI = UriBuilder 


.fromPath ("http://localhost : 8080" 
+contextPath + "/site/index.xhtml") 


.queryParam("msg", "Compra realizada com sucesso") 
.build(); 
Response response = Response. seelther (redirectURI) 
.build(); 


return response; 


Por conta do CDI, conseguimos receber todas as nossas dependências in- 
jetadas. O código em si, até a parte da integração, é o mesmo que tinha no 
bean do JSF. A parte nova é o tipo de retorno do nosso método. Perceba que, 
quando acabamos a integração, devolvemos um objeto do tipo Response, e 
aqui entra um pouco mais de teoria sobre o HTTP. 


O método seeother da classe Response monta um objeto cuja res- 
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posta gerará o status 303, também conhecido como See Other. Esse status 
deve ser usado quando queremos notificar o cliente da requisição de que ele 





deve pegar a resposta e acessar a URI retornada por meio de um GET. 

Este é um dos pilares do JAX-RS: prover abstrações para trabalharmos 
de maneira direta com o HTTP, usando o protocolo como alicerce para as 
integrações que vamos implementar dentro da nossa aplicação. 

Outro detalhe importante é o uso da annotation @Path para indicar 
qual o endereço base do nosso recurso. Qualquer método que vá ser aces- 
sado dentro dessa classe será solicitado por meio de um endereço no estilo 
payment /*. Por exemplo, configuramos o método que realiza a integração 
para ser acessado apenas via POST. 


@POST 
public Response pay(@QueryParam("uuid") String uuid) { 


Poderiamos, inclusive, ter adicionado mais um @Path em cima do mé- 
todo. Dessa forma, teríamos um endereço específico para ele. Optamos ape- 
nas por diferenciar o acesso através do verbo HTTP. Perceba o endereço que 
aparece no navegador, depois de clicarmos no botão de finalização de compra. 


http://localhost:8080/casadocodigo/services/payment 


*uuid=1234567890123456789 
Ainda tem uma parte do endereço, o /services, que não desvendamos. 


Segure um pouco a ansiedade, temos de caminhar com calma. 


Tratando a requisição de maneira assíncrona 


Para fechar, só precisamos fazer com que o código de integração com o 


sistema externo rode em um contexto assíncrono. Isso já é suportado pelo 


próprio JAX-RS, por conta da sua integração com a especificação de Servlets. 


OPath ("payment") 
public class PaymentResource { 


private static ExecutorService executor = 
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Executors .newFixedThreadPool(50); 
@Context 
private ServletContext ctx; 
@Inject 
private CheckoutDAO checkoutDao; 
@Inject 
private PaymentGateway paymentGateway; 


@POST 
public void pay(@Suspended final AsyncResponse ar, 
@QueryParam("uuid") String uuid) { 


String contextPath = ctx.getContextPath() ; 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 


executor.submit(() -> { 


BigDecimal total = checkout.getValue(); 


try É 
paymentGateway.pay (total); 


URI redirectURI = UriBuilder 
. fromUri (contextPath + 
"/site/index. xhtml") 
.queryParam("msg", 
"Compra realizada com sucesso") 
.build(); 


Response response = Response 


.seeOther (redirectURI) .build(); 
ar .resume (response) ; 


} catch (Exception exception) { 
ar .resume (exception); 


p); 
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Respire fundo. Vamos olhar com carinho para o código que acaba- 
mos de escrever. O primeiro detalhe é que usamos um objeto do tipo 





ExecutorService 


private static ExecutorService executor = 
Executors.newFixedThreadPool (50) ; 


Existem várias implementações dessa interface para criarmos um pool de 
threads, muito similar ao que já fazemos quando criamos um pool de conexões. 
A ideia é não ter de ficar criando novas threads o tempo inteiro. O atributo é 
estático, porque você quer usar o mesmo pool para tratar todas as requisições. 





O ExecutorService possui o método submit, no qual precisamos 
passar uma instância de alguma implementação de Runnable. Para não 
termos de ficar usando classes anônimas, recorremos para o uso dos lambdas 
do Java 8. 


executor. submit(() -> { 
BigDecimal total = checkout .getValue(); 


try { 
paymentGateway.pay (total); 


URI redirectURI = UriBuilder 
. fromUri (contextPath + "/site/index.xhtml") 
.queryParam("msg", 
"Compra realizada com sucesso") 
.buildQ ; 


Response response = Response. see0ther (redirectURI) 


.build(); 
ar.resume (response) ; 


} catch (Exception exception) { 
ar.resume (exception); 
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}); 


Agora vem a parte que faltava para o nosso código funcionar: o objeto 
do tipo AsyncResponse. Essa é a abstração do JAX-RS para notificarmos o 
servidor de que nossa execução assincrona foi finalizada. 


@POST 
public void pay(@Suspended final AsyncResponse ar,...){ 
executor.submit(() -> { 


BigDecimal total = checkout.getValue(); 
try {í 
//codigo de integração 


Response response = Response.seeOther (redirectURI) 
.build(); 
ar .resume (response) ; 


} catch (Exception exception) { 
ar.resume (new WebApplicationException(exception) ) ; 


HW; 


O método resume é o responsável por fazer a notificação de que nossa 
tarefa assíncrona foi finalizada. Para que tudo funcione, precisamos anotar o 
parâmetro do tipo AsyncResponse com a annotation @Suspended. Ela é 
usada para indicar para o container que o método em questão deve ser exe- 
cutado em um contexto assíncrono. 

Pronto, agora fazemos o código de comunicação com o sistema externo 
sem bloquear o nosso servidor! Essa é uma ótima técnica, tarefas demoradas 
não precisam e não devem ser executadas na thread que atende a requisição 
em si. 
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8.8 CONFIGURANDO O JAX-RS 


Para que tudo funcione, só faltou resolver a configuração responsável por as- 
sociar o padrão de endereço /services/+ para qualquer Resource do 
JAX-RS. Essa configuração não poderia ser mais simples, basta que criemos 
uma classe-filha de Application. 


package br.com.casadocodigo.loja.resources; 


import javax.ws.rs.ApplicationPath; 
import javax.ws.rs.core. Application; 


@ApplicationPath("/services") 
public class JaxRsConfiguration extends Application { 


Além de herdarmos de Application, anotamos a classe com 
ApplicationPath e definimos qual o endereço base. É justamente por isso 
que, quando fomos acessar o Resource responsável pelo pagamento, será 
usado o endereço services/payment. 

Outra maneira de realizar a mesma configuração é utilizar o web.xml. 
Como nossa aplicação é web, basta que adicionemos um Servlet específico. 


<servlet> 
<servlet-name>javax.ws.rs.core. Application</servlet-name> 
</servlet> 
<servlet-mapping> 
<servlet-name>javax.ws.rs.core. Application</servlet-name> 
<url-pattern>/services/*</url-pattern> 
</servlet-mapping> 


O detalhe importante aqui é o valor da tag servlet-name. É obriga- 
tório que seja usado javax.ws.rs.core.Application. A especifica- 
ção obriga que a implementação do JAX-RS registre, dinamicamente, uma 
Servlet exatamente com esse nome. E aí, no url-pattern, colocamos o 
nosso padrão de URL base. 

Este autor sempre prefere configurações baseadas em código Java, então 
é com a primeira opção que vamos seguir no livro. 
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8.9 CURIOSIDADE: USANDO UM EXECUTORSERVICE 
GERENCIADO 


No nosso código de integração, fomos nós que ficamos responsáveis pela cri- 
ação de um pool de threads. Por mais que isso funcione, temos de ficar atentos 
pois, no momento que decidimos usar um recurso não injetado pelo servidor, 
passamos a ter que talvez nos preocupar com alguns detalhes a mais de infra- 
estrutura. Por exemplo, tivemos de decidir o número de threads disponíveis 
nos nossos pools. 

Sabendo que certos códigos precisam ser executados em outras threads, o 
Java EE, na versão 7, trouxe uma nova especificação, a JAVA EE Concurrency 
Utilities. Vamos ver como poderia ficar nosso código de integração com o 
meio de pagamento. 


@Path ("payment") 
public class PaymentResource { 


@Context 
private ServletContext ctx; 
@Inject 
private CheckoutDAO checkoutDao; 
@Inject 
private PaymentGateway paymentGateway; 
@Resource(name = 
"java: comp/DefaultManagedExecutorService") 
private ManagedExecutorService managedExecutorService; 


@POST 
public void pay(@Suspended final AsyncResponse ar, 
@QueryParam("uuid") String uuid) { 


String contextPath = ctx.getContextPath() ; 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 


managedExecutorService.submit(() -> { 
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BigDecimal total = checkout.getValue(); 


try { 
paymentGateway.pay (total); 


URI redirectURI = UriBuilder 
.fromUri (contextPath + 
"/site/index.xhtml'!) 
.queryParam("msg", 
"Compra realizada com sucesso") 
.build(); 


Response response = 


Response. seeOther (redirectURI) .build(); 
ar.resume(response) ; 


} catch (Exception exception) { 
ar.resume (exception); 


Hs 





A novidade é que, em vez de usar a interface ExecutorService, pas- 





samos a usar a ManagedExecutorService. Perceba que a injeção foi feita 
por meio da annotation @Resource. Também tivemos de usar a chave 





java: comp/DefaultManagedExecutorService, que é o nome imposto 
pela especificação que deve estar disponível na JNDI. 

A alteração em si foi simples, mas ainda temos outros ganhos não tão 
explícitos. Por exemplo, nosso código pode necessitar de transações, EJBs, 
segurança e muitos outros detalhes que estamos analisando durante a cons- 
trução do projeto. Quando você inicia uma thread manualmente, tudo isso é 
perdido, já que o servidor não tem conhecimento desse recurso. Quando usa- 





mos um ExecutorService gerenciado pelo servidor de aplicações, temos 
a garantia de que os devidos contextos serão propagados, o que nos permite 
focar na nossa regra de negócio do que em detalhes de infraestrutura. 
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8.10 CONCLUSÃO 


Este foi um capítulo bem denso. Usamos novos status do HTTP, adicionamos 
o JAX-RS na nossa aplicação para lidar com requisições não relacionadas com 
o JSF, e ainda discutimos como lidar com requisições potencialmente demo- 
radas, delegando a execução para o contexto assincrono do servidor. 

Minha sugestão, assim como foi no último capítulo, é que você pare um 
pouco para digerir tudo o que fizemos. No próximo passo da nossa aven- 
tura, vamos debater sobre cache e como isso pode ajudar na performance da 
aplicação, com certeza um tópico mais simples e de fácil compreensão. 
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Melhorando a performance com 
cache 


Sempre que entramos no site da Casa do Código, ele nos mostra um monte de 
livros que podemos comprar. O leitor mais atento ja deve ter percebido que 
essa listagem nao muda muito dentro de um determinado intervalo de tempo. 
E o fato de não mudar nos leva a um questionamento: será que realmente 
precisamos ficar executando as duas consultas todas as vezes em que um usuário 
acessar essa página? 


9.1 CACHEANDO O RETORNO DAS CONSULTAS NA JPA 


Apenas para refrescarmos a memória, na home da Casa do Código exibimos 
duas listagens de livros: a primeira com os principais lançamentos e a segunda 
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com outros livros da editora. 

Atualmente, toda vez que um novo usuário acessa a aplicação, essas con- 
sultas devem ser realizadas no banco de dados. Caso os dados mudassem em 
cada uma das consultas, até faria sentido buscar as informações o tempo todo, 
mas nessa situação em específico, os livros retornados são sempre os mesmos. 

Uma das principais ações que podemos realizar para melhorar a perfor- 
mance da aplicação é justamente minimizar o acesso ao banco de dados, guar- 
dando os retornos em um cache. Na verdade, isso pode ser aplicado para 
qualquer parte do seu sistema que busque informações de uma aplicação ex- 
terna. 

Para a nossa alegria, o Hibernate já suporta que o resultado de certas que- 
ries do sistema devam ser guardados na memória. Esse cache compartilhado 





entre várias instâncias do EntityManager é conhecido como Second Level 
Cache. 


public class BookDAO 1 


@PersistenceContext 
private EntityManager manager; 


public List<Book> lastReleases() { 
TypedQuery<Book> query = manager 
.createQuery ( 
"select b from Book b where b.releaseDate 
<= now() order by b.id desc", 
Book.class) .setMaxResults(3) ; 


query.setHint (QueryHints.HINT_CACHEABLE, true); 
return query.getResultList (); 
public List<Book> last(int number) { 


TypedQuery<Book> query = manager 
.createQuery("select b from Book b 
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join fetch b.authors", 
Book.class) .setMaxResults (number) ; 


query .setHint (QueryHints.HINT CACHEABLE, true); 


return query.getResultList () ; 


O método setHint espera como argumento uma String informando 
o nome da configuração que queremos definir, assim como seu valor. A cons- 
tante HINT CACHEABLE guarda o valor org.hibernate.cacheabl 














Caso estivéssemos usando diretamente a API do Hibernate, poderia ter 
sido usado método setCacheable. O setHint foi a maneira encontrada 





pela especificação para podermos invocar alguns detalhes da implementação 
sem recorrer às suas classes. 

Agora, se tentarmos acessar o endereço site/index.xhtml e obser- 
varmos o console do WildFly, vamos perceber que a query ainda está sendo 
executada todas as vezes. O cache de query não está habilitado por padrão. 
Como é uma configuração muito sensível, o Hibernate exige que você, por 
vontade própria, habilite o uso do cache de consultas. Precisamos alterar o 


arquivo persistence.xml. 


<persistence-unit name="casadocodigo-persistence-unit" 
transaction-type="JTA"> 


<properties> 


<property name="hibernate.cache.use query cache" 
value="true"/> 
</properties> 
</persistence-unit> 


A configuração de cache de queries ainda não é suportada pela especifica- 
ção, então usamos chaves específicas do Hibernate. Após essa configuração, 
quando tentamos iniciar o servidor, recebemos uma exception. 
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Caused by: 

org. hibernate.cache.NoCacheRegionFactoryAvailableException: 
Second- level cache is used in the application, but property 
hibernate.cache.region.factory_class is not given; please either 
disable second level cache or set correct region factory using 
the hibernate.cache.region.factory_class setting and make sure 
the second level cache provider (hibernate-infinispan, e.g.) is 
available on the classpath. 


Informamos que queremos habilitar o cache de queries, mas ainda preci- 
samos configurar o Hibernate para usar o cache de segundo nível de maneira 
geral. Podemos cachear muito mais do que queries, e vamos fazer isso na 
continuação deste capítulo! 


<persistence-unit name="casadocodigo-persistence-unit" 
transaction-type="JTA"> 


<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> 
<properties> 


<property name="hibernate.cache.use_query_cache" 
value="true"/> 
</properties> 
</persistence-unit> 





A tag shared-cache-mode da JPA deve ser usada para informarmos 
como vamos decidir quais objetos devem ser cacheados. Vamos pensar um 
pouco mais sobre isso. Quando fazemos uma consulta por meio da JPA, geral- 
mente é retornada uma lista de objetos. Essa configuração serve para termos 
a possibilidade de dizer quais tipos de objetos devem ser mantidos em cache. 




















Aopção ENABLE SELECTIVE é a mais utilizada, pois permite que o progra- 





mador defina exatamente quais entidades podem ser mantidas na memória. 


Veja quais são as outras opções: 


e ALL - todas as entidades podem ficar no cache. Geralmente não usa- 
mos essa opção, pois nem toda entidade merece ser cacheada. 
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* NONE - nenhuma entidade pode ir para o cache. Só seria usada se a 


aplicação realmente quiser deixar explícito que nada pode ser cache- 


ado. 





e DISABLE SELECTIV 

















E — parte do princípio que todas as entidades po- 


dem ficar no cache. Dessa forma, o programador deve ir configurando 


cada entidade que não pode ser cacheada. 


Com nossa configuração feita, chegou a hora de acessarmos a página 


inicial do site. Porém, quando o fazemos, percebemos um comportamento 


muito estranho: diversas consultas estão aparecendo no console do servidor. 


Hibernate: 

select 
book0 .id as idi 1 0, 
book0O .coverPath as coverPat2 1 0, 
book0. .description as descript3_1_0_, 
book0. .number0fPages as number0f4 1 0.,, 
book0. .price as price5_1_0_, 
book0 .releaseDate as releaseD6 1 0, 
bookO_.summaryPath as summaryP7_1_0_, 
bookO_.title as title8_1_0_ 

from 
Book book0_ 

where 
book0_.id=? 

Hibernate: 

select 
book0 .id as idi_1i_0_, 
book0O_.coverPath as coverPat2_1_0_, 
bookO_.description as descript3_1_0_, 
book0. .number0fPages as number0f4_1_0_, 
book0. .price as price5_1_0_, 
book0 .releaseDate as releaseD6 1 0, 
bookO_.summaryPath as summaryP7_1_0_, 
bookO_.title as title8_1_0_ 

from 
Book book0_ 

where 
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book0_.id=? 
Hibernate: 

select 
bookO_.id as idi_1_0_, 
book0O .coverPath as coverPat2_1_0_, 
bookO_.description as descript3_1_0_, 
book0. .number0fPages as number0f4_1_0_, 
bookO_.price as price5_1_0_, 
bookO_.releaseDate as releaseD6_1_0_, 
bookO_.summaryPath as summaryP7_1_0_, 
bookO_.title as title8_1_0_ 

from 
Book book0_ 

where 
book0_.id=? 

Hibernate: 

select 
bookO_.id as idi_1_0_, 
book0_.coverPath as coverPat2_1_0_, 
bookO_.description as descript3_1_0_, 
book0. .number0fPages as number0f4_1_0_, 
bookO_.price as price5_1_0_, 
book0O_.releaseDate as releaseD6_1_0_, 
bookO_.summaryPath as summaryP7_1_0_, 
bookO_.title as title8_1_0_ 

from 
Book book0_ 

where 
book0_.id=? 


Entendendo exatamente como funciona o cache de segundo nivel 


As implementações de cache, em geral, são estruturas baseadas em ma- 


pas. Quando pedimos para o Hibernate deixar o resultado das consultas no 


cache, o que ele faz, por baixo dos panos, é justamente adicionar uma entrada 


nesse mapa, associando o retorno da consulta. É justamente aqui que está 


nosso problema. Para o cache de query, são armazenados apenas os ids das 


entidades retornadas, não os objetos completos. 
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Internamente, as entradas do cache são divididas nas chamadas regiões. 
Elas servem para que a aplicação possa, por exemplo, limpar toda uma região 
de cache. 


//exemplo para limpar o cache pela API do Hibernate 

entityManagerFactory. 
unwrap(SessionFactory.class).getCache(). 
evictQueryRegion("algumaRegiao") ; 


Também podemos acessar o cache de segundo nível diretamente pela API 
da JPA, mas ela ainda nos oferece menos opções. Não conseguimos limpar 
uma região especificamente, por exemplo. Veja um exemplo de como você 
poderia acessá-lo: 


Cache cache = entityManagerFactory () .getCache() ; 
cache.evictAll(); 


No fim, o que acontece é que, para cada id encontrado no cache da query 
específica, o Hibernate vai buscar por esse mesmo id na região do cache da 
entidade específica. Como ele não encontra, faz um select para buscar os 
dados de determinada entidade. 


Habilitando a entidade para ser cacheada 


Para resolvermos o nosso problema, basta que seja adicionada uma an- 
notation na entidade que está participando da query. 


package br.com.casadocodigo.loja.models; 


import javax.persistence.Cacheable; 
CEntity 


@Cacheable 
public class Book { 


Perceba que essa annotation também é da especificação. Agora sim, se 
tentarmos acessar a página inicial da aplicação duas vezes, vamos perceber 
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que, a partir da segunda, as consultas param de ser feitas. Sempre que você 
pensar em cache de segundo nível, comece anotando as entidades para não 
cair neste tipo de problema. 


Com a entidade anotada, ainda ganhamos de brinde o cache da entidade 





quando usamos o método find do EntityManager. Quando você tentar 
acessar a página de detalhes de um livro, perceberá que só a consulta dos 
autores do livro vai ser disparada, por conta do Lazy Load, mas não mais a da 
entidade. 


9.2 PROVIDER DE CACHE E SUAS CONFIGURAÇÕES 


Quando optamos por usar o cache de segundo nível, somos obrigados a deci- 
dir qual será a implementação usada para manter os dados em memória. Em 
um sistema sendo executado fora de um servidor de aplicação, a opção mais 
natural tem sido usar o EhCache. 

Como estamos rodando dentro do WildFly, já estamos utilizando uma 
implementação chamada Infinispan. Não foi necessário fazer nenhuma confi- 





guração relativa a isso, pois a implementação do EntityManagerFactory 
usada pelo WildFly já usa o Infinispan por default. 


Configurando o timeout 


Um ponto muito relevante sobre o cache é o tempo que os objetos devem 
viver nele. Por exemplo, os detalhes de um livro pouco mudam com o passar 
do tempo. O máximo que acontece é atualização de detalhes internos dos 
capítulos por conta de uma errata, ou atualização de tecnologia. 

Pensando nesse cenário, podemos colocar um tempo de expiração bem 
alto, especificamente para a entidade Book. O Infinispan permite que essas 
configurações sejam adicionadas no próprio persistence.xml. 


<persistence-unit name="casadocodigo-persistence-unit" 
transaction-type="JTA"> 


<properties> 
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<!-- infinispan cache --> 

<property 
name="hibernate.cache.infinispan.br.com.casadocodigo 
.loja.models.Book.expiration.lifespan" 

value= "900000"/> 


</properties> 
</persistence-unit> 


É importante notar que essa é uma configuração específica do Infinispan. 
Caso o seu projeto utilize, por exemplo, o EhCache, a configuração já será 
diferente. No caso específico do EhCache, ela seria feita em um arquivo sepa- 
rado, chamado de ehcache.xm1. O valor deve ser passado em milissegun- 
dos, por isso informamos 900000, que representa 15 minutos. Na verdade, 
podemos passar bem mais, pensando que os livros realmente não são atuali- 
zados frequentemente. 

Outro ponto importante para ser notado é o nome da chave de configu- 
ração. Basicamente, ele obedece a um template imposto pelo Inifinispan. 


hibernate.cache. infinispan.NOME COMPLETO ENTIDADE 
.expiration.lifespan 


Caso você queira definir um tempo padrão 
para qualquer entidade anotada, pode usar a opção 
hibernate.cache.infinispan.entity.expiration 
.expiration.lifespan 

Existem diversas outras configurações que podem ser feitas. É aconse- 
lhado que o leitor acesse o link http://bit.ly/conf-infinispan. 


9.3 INVALIDACAO DO CACHE POR ALTERAÇÃO 


Um último detalhe importante que deve ser lembrado é sobre a invalidação 
dos dados que estão presentes no cache. Por exemplo, todo cache de query 
é automaticamente invalidado quando realizamos qualquer operação com as 
entidades pertencentes ao cache. 

No nosso caso, quando inserimos um novo livro, os caches das queries 
relacionadas à classe Book são desfeitos. A motivação é simples: a mesma 
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query, a partir de agora, pode trazer um resultado diferente e, por conta disso, 
o cache é invalidado. 

Uma outra situação, não de invalidação, mas de alteração do estado do ca- 
che, acontece quando alteramos um objeto que está sendo buscado via find. 
Por exemplo, se um livro for colocado no cache e, posteriormente, seus dados 





forem alterados via Ent it yManager, as novas informações vão ser atualiza- 
das no cache. Como estamos rodando dentro de um servidor de aplicação, a 
alteração vai ser realizada dentro da mesma transação JTA que o objeto tiver 
sido modificado. 


9.4 CACHEANDO TRECHOS DA PAGINA 


Nesse exato momento, o nosso cache está restrito ao nosso acesso ao banco 
de dados, só que podemos ir ainda além. Na home da loja, o tempo inteiro 
processamos o trecho de xhtml responsável por exibir as lista, e a pergunta 
que fica é: por que estamos fazendo isso? 

Como esses trechos não mudam por um bom tempo, não temos a ne- 
cessidade de ficar processando eles sempre. O OmniFaces, biblioteca que já 
usamos quando foi necessário personalizar as mensagens de erro do formu- 
lário de checkout, também provê uma tag utilitária para guardar trechos de 
página no cache. 


Vamos fazer uma leve alteração no arquivo site/index.xhtml. 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmins:pt="http://xmins.jcp.org/jsf/passthrough" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui"> 


<o:cache> 
<ul id="home-highlight-collection"> 
<ui:repeat var="book" 
value="#{homeBean. lastReleases() }"> 
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<li class="col-left"> 
<a href="#{request .contextPath}/site 
/detalhe.xhtml?id=#{book.id}" 
class="block clearfix"> <img width="170" 
height="240" 
src="#{book.coverPath}" 
alt=" #{book.title}" 
title="#{book.title}"/> 
<h2 class="product-title"> 
#{book. title} 


</h2> 
<small class="buy-button"> 
Lan&4231;amento! 
</small></a> 
</li> 
</ui:repeat> 


</ul> 
</o:cache> 


<o:cache> 
<ul class="clearfix book-collection"> 


<ui:repeat var="book" 
value="#{homeBean.olderBooks() }"> 
<li><a href= 
"#{request . contextPath}/site/detalhe. xhtml? 
id=#{book.id}" class="block clearfix"> 
<h2 class="product-title"> 
#{book. title} 


</h2> 
<img width="143" 
height="202" 


src="#{book.coverPath}" 

alt="#{book.title}" 

title="#{book.title}"/><small 

class="buy-button'">Compre</small> 
</a></1i> 
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</ui:repeat> 
</ul> 
</o:cache> 


</html> 


Adicionamos o namespace do OmniFaces na tag HTML e usamos a tag 
cache. O uso é bem direto, basta envolvermos o trecho que só queremos que 
seja executado uma vez com a tag cache, e a mágica está feita. O OmniFaces 
vai executar o trecho na primeira vez que o usuário entrar na página e, a partir 
da segunda, recuperará o valor do cache e entregará para o JSF. 

O leitor mais atento vai perceber que, a partir do segundo acesso, nem 
os logs do Hibernate são mais gerados. Isso justamente porque a expression 
language envolvendo o #{homeBean.metodo} não é mais executada. Por 
padrão, o OmniFaces vai manter o cache atrelado à sessão do usuário e, caso 
o trecho possa ser reaproveitado para qualquer usuário, podemos usar o atri- 


buto scope. 


<o:cache scope="application"> 
</o: cache> 


Ainda é possível especificar diversas outras propriedades na tag de cache 
do OmniFaces. 


e reset — você pode passar uma expression language cujo retorno é um 
booleano. O OmniFaces vai descartar o cache toda vez que a expressão 


retornar false. 


* time — tempo em segundos para o seu cache expirar. Essa é uma pro- 
priedade bem importante, todo código cacheado deveria ter uma con- 
figuração clara de quando ele vai expirar. 


Por fim, caso sua aplicação precise definir um valor padrão de maneira 
global, o mesmo pode ser feito no arquivo web.xml. 


<context-param> 
<param-name> 
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org.omnifaces.CACHE SETTING APPLICATION TTL 
</param-name> 
<param-value>900</param-value> 
</context-param> 


Aqui dizemos que os trechos de cache associados à aplicação inteira de- 
vem permanecer na memória por, no máximo, 15 minutos. 

Relembrando que o OmniFaces é uma biblioteca que realmente tem mui- 
tos componentes utilitários, considere-o como parte integrante do seu dia a 
dia de desenvolvimento com o JSF 


9.5 CONCLUSÃO 


Este foi um capítulo mais curto, mas muito importante. Habilitar o cache 
pode fazer gerar um bom impacto de performance na sua aplicação. No en- 
tanto, seja pragmático e faça testes de performance para ver se o impacto es- 
perado realmente é o atingido. 

Outro ponto importante é que colocar objetos, trechos de página e qual- 
quer outra coisa no cache, muitas vezes, tem a ver com uma decisão de negó- 
cio. Por exemplo, na Casa do Código, o dono do produto pode ter informado 
que os livros são atualizados semanalmente. Sem essa informação, não pode- 
ríamos ter deixado as listagens por tanto tempo na memória. 

Encerrando as preocupações, lembre-se de que ter muitos objetos na me- 
mória incrementa o consumo, o que pode levar, por conta de um uso exa- 
gerado, à falta de memória em algum momento. Lembre sempre de definir 
políticas de expiração de cache para ter um controle mais fino relativo a isso. 

Minha dica é que você não pare de ler agora, este capítulo foi mais tran- 
quilo e o próximo também será! Nele, vamos possibilitar que os dados da 
nossa aplicação sejam exibidos por outros tipos de aplicações, não apenas na- 
vegadores. 
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Respondendo mais de um 
formato 


Nossa aplicação, até o presente momento, lida com requisições vindas de um 
navegador, só que agora vamos um pouco além do que já existe na Casa do 
Código. Sites de vendas muito grandes, como a Amazon e o Submarino, além 
de exporem os seus produtos, fazem parcerias com outros sites para que essas 
outras aplicações também possam exibi-los. 


10.1 EXPONDO OS DADOS EM OUTROS FORMATOS 


Quando falamos de integração com outras aplicações, o primeiro ponto em 
que temos que pensar é: qual é o formato que vamos usar para realizar a in- 
tegração? 
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Atualmente, nossa aplicação só é capaz de retornar páginas para os clien- 
tes, no caso os navegadores, em HTML. Um outro tipo de cliente, hoje já muito 
comum, são os celulares com Android ou iOS. E como você já deve esperar, 
exibir dados através de HTML pode não ser o formato ideal para ser usado 
nesses aparelhos. 

Para conseguir retornar formatos de respostas diferentes, teremos de usar 
o JAX-RS, já que o JSF não suporta outro tipo de resposta que não seja HTML. 
Como já fizemos toda parte de configuração do JAX-RS, basta que criemos 
um Resource para responder aos formatos que desejamos. 


package br.com.casadocodigo.loja.resources; 
//imports 


@Path("books") 
public class BooksResource { 


@Inject 
private BookDAO bookDAO; 


@GET 

@Produces({ MediaType. APPLICATION_JSON}) 

@Path("json") 

public List<Book> lastBooksJson() { 
return bookDAQO.lastReleases() ; 


Perceba que o código foi bem direto. Criamos um método, retornamos a 
lista de livros e usamos a annotation GP roduces para dizer que este método 
suporta devolver a resposta no formato JSON. Por conta do CDI, mais uma 
vez, podemos receber tudo o que precisamos injetado. 


Para fechar, usamos a annotation @Path para definir o endereço base 





do Resource, e a annotation @GET para dizer que este método só pode ser 
acessado por meio de requisições que usem este verbo. 


Uma pergunta que pode ficar na cabeça é: por que o verbo de acesso só 
pode ser get? O principal motivo é a semântica da operação. Um get re- 
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presenta que a informação está sendo buscada, e uma consequência disso é 
que o cliente pode fazer diversas requisições para este endereço, que ele sabe 
que nunca vai alterar o estado do servidor, por exemplo. Diferente de quando 
usamos um POST para validar o pagamento, no capítulo 8. O POST sempre 
indica que algo vai ser criado no servidor, então, se o cliente faz duas requi- 
sições com os mesmos dados usando este verbo, ele tem de estar consciente 
que algo pode dar errado. 

Para testarmos se nosso código está retornando a resposta que deveria, 
podemos usar o curl. 


curl -X GET "http://localhost:8080/casadocodigo/services 
/books/json" 


O leitor mais curioso que está tentando executar a requisição deve ter 
percebido que o resultado não foi completo. Só foi retornando um livro e, 
mesmo assim, faltando a relação de autores. Veja um exemplo de resultado: 


L 
{ 
"id": 60, 
"title": "JAVAEE", 
"description": "Uma aplicação completa usando o que...", 
"number0fPages": 200, 
"price": 50, 
"author": [] 
} 
] 


O motivo fica claro quando vamos olhar no console do servidor. 


Caused by: org.hibernate.LazyInitializationException: failed to 
lazily initialize a collection of role: 
br.com.casadocodigo.loja.models.Book.authors, 

could not initialize proxy - no Session 


Fomos, novamente, surpreendidos pelo Lazy Load. Vamos relembrar 


como está o método lastReleases na classe BookDAO: 
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public List<Book> lastReleases() { 


TypedQuery<Book> query = manager 
.createQuery ( 
"select b from Book b where b.releaseDate 
<= now() order by b.id desc", 
Book.class) .setMaxResults(3) ; 
query .setHint (QueryHints.HINT CACHEABLE, true); 
return query.getResultList (); 


Os autores só vão ser carregados no momento em que o método 


getAuthors for invocado. Como este só é chamado na hora de transfor- 


mar o objeto do tipo List <Book> para JSON, o objeto não está ligado ao 





EntityManager. É exatamente o mesmo problema que tivemos na tela de 


detalhes do livro, o objeto entra no estado detached. Para a nossa sorte, a 


solução é a mesma. Transformamos nosso Resource em EJB stateful e 





trabalhamos com o EntityManager extended. 


@Path("books") 
@Stateful 
public class BooksResource { 
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@PersistenceContext (type=PersistenceContextType. EXTENDED) 
private EntityManager entityManager; 
private BookDAO bookDAO; 


@PostConstruct 
private void loadDAO(){ 
this.bookDAO = new BookDAO(entityManager) ; 


@GET 

@Produces({ MediaType. APPLICATION_JSON}) 

@Path("json") 

public List<Book> lastBooksJson() { 
return bookDAO.lastReleases(); 
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De novo, por mais que essa solução nos faça escrever um pouco mais de 
código, deixamos tudo muito claro. Por sinal, esse problema também pode- 
ria ter sido resolvido planejando melhor as queries e usando mais fetch joins. 
Como já discutimos, o lado ruim do fetch é que as nossas queries ficarão 
mais complicadas. 

Este autor prefere um uso conjunto, analisando cada uma das situações. 
Caso você tenha um objeto muito complexo, pode planejar a query e trazer 
só o necessário. Caso contrário, pode apostar um pouco mais no Lazy Load. 

Antes de avançarmos, vale uma última observação. Só foi possível o uso 
do @Stateful, pois todo Resource do JAX-RS é criado e destruído por 





request e, com isso, é garantido que nosso EntityManager também só verá 


esse escopo. Caso tivéssemos um objeto com um escopo maior, por exemplo 





de sessão, o EntityManage extended viveria por um tempo mais longo, 
o que, na maioria dos casos, não é o que precisamos. 

Agora, se rodarmos o mesmo comando para executar o request, recebe- 
mos a resposta completa! Nesse momento, nossa aplicação consegue retornar 
os livros em JSON, além das páginas HTML. 

E se nosso cliente precisar de um retorno em XML? Teríamos de criar 
outro método e informar que o retorno é do tipo XML. ;( 


@GET 
@Produces({ MediaType. APPLICATION_XML}) 
@Path("xm1") 
public List<Book> lastBooks() { 
return bookDAO. lastReleases( 


Agora, se tentarmos fazer a requisição para o novo endereço, esperamos 
obter o XML esperado. O problema é que, em vez disso, recebemos uma ex- 
ception. 


Could not find MessageBodyWriter for response object of type: 
java.util.ArrayList of media type: application/xml 
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JAX-B e um pouco de burocracia 


A especificação responsável por definir as regras de serialização de objetos 
em XML (e vice-versa) é JAX-B. Ao contrário de várias outras especificações 
que foram evoluindo com o passar do tempo, ela ainda exige uma configura- 
ção maior do que a desejada. Por exemplo, perceba que, para gerar o JSON, 
não precisamos fazer nada de muito especial. 

Seguindo a exception ao pé da letra, entendemos que não conseguimos 
serializar um objeto do tipo ArrayList, pois o JAX-RS não encontrou 
ninguém capaz de realizar este trabalho. O problema é que o JAX-B exige 
que a classe do objeto sendo serializado utilize uma annotation chamada 





@XmlRootElement. Só que, parando para pensar, como vamos adicionar 
uma annotation na classe ArrayList, teríamos de criar uma nova classe, 
que teria a annotation e aí declararia um atributo do tipo ArrayList. 


0XmiRootElement 
public class Books { 
private List<Book> list = new ArrayList<>(); 


Para a nossa sorte, o RestEasy, implementação do JAX-RS usada pelo Wi- 
dlFly, suporta que mantenhamos o retorno do tipo List. Por baixo do pano, 
ele envelopa a lista retornada em um objeto específico dele. 

De todo jeito, agora somos obrigados a anotar a classe que representa o 
tipo da lista, nesse caso, a Book. 


CEntity 

@Cacheable 
@XmlRootElement 
public class Book { 


Da maneira como está, já conseguimos gerar um retorno do servidor. 
Caso executemos o curl mais uma vez, o resultado deve ser parecido com: 


<collection> 
<book> 
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<authors> 

<id>1</id> 

<name>Alberto Souza</name> 
</authors> 
<authors> 

<id>2</id> 

<name>Mauricio Aniche</name> 
</authors> 
<description> 


</description> 

<id>59</id> 
<number0fPages>100</number0fPages> 
<price>100.00</price> 


</book> 

<book> 

</book> 
</collection> 

Tem alguns detalhes estranhos nesse XML. O primeiro é o nome da tag 

pai, collection. Esse é justamente o nome atributo da classe do RestEasy, 
que serve de wrapper para a nossa coleção. Não que isso seja um problema 
do tamanho do mundo, mas, para o nosso cenário, o melhor é que a tag se 


chamasse books. Para deixar isso flexível, o RestEasy fornece uma annota- 
tion. 


@GET 
@Produces({ MediaType. APPLICATION_XML}) 
@Path("xm1") 
@Wrapped(element="books") 
public List<Book> lastBooks() { 
return bookDAO. lastReleases(); 


A annotation @Wrapped faz o trabalho que queremos. Agora, se pedir- 
mos pelo XML, ele virá com a tag books como a principal. É importante 
ressaltar que essa é uma annotation do RestEasy, e não da especificação. Caso 
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você não queira sair da especificação, vai ter de partir para a criação da classe 
wrapper, só que manualmente. 

Outro ponto estranho é que cada autor está especificado em uma tag cha- 
mada authors. 


<authors> 

<id>1</id> 

<name>Alberto Souza</name> 
</authors> 
<authors> 

<id>2</id> 

<name>Mauricio Aniche</name> 
</authors> 


O mais comum seria algo parecido com: 


<authors> 
<author> 
<id>4</id> 
<name>Paulo Silveira</name> 
</author> 
<author> 
<id>5</id> 
<name>Sergio Lopes</name> 
</author> 
</authors> 


Para atingirmos essa estrutura, vamos precisar usar mais algumas anno- 
tations do JAX-B. 


@XmlRootElement 
@XmlAccessorType (XmlAccessType. FIELD) 
public class Book { 


0XmlElement (name="author") 
@Xm1ElementWrapper (name="authors") 
private List<Author> authors = new ArrayList<>(); 
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A @XmlAccessorType é usada para informarmos a implementação 
do JAX-B que nossas configurações vão ser baseadas nos atributos. O pa- 
drão é que ele busque as configurações em cima dos getters. Já a 





@XmlElementWrapper serve justamente para dizermos que todos os ob- 
jetos da lista em questão devem vir dentro de uma tag chamada authors. 





Por fim, usamos a @Xm1Element para configurar que cada objeto do tipo 
Author deva vir dentro de uma tag chamada de author. 

Podemos customizar bastante a geração do XML, tudo vai depender da 
necessidade da aplicação que estiver consumindo. Claro que o melhor é não 
precisarmos mexer em nada, mas nem sempre isso é possível. 


Também é importante prestar atenção no uso da annotation 





@XmlElement, que influencia na geração do JSON. Antes, o nome da 
propriedade que referenciava os autores era authors, mesmo nome do 
atributo. Agora é author, dada a nossa configuração. Este é um problema 
que a especificação do Java EE ainda precisa atacar: normalizar a geração de 
JSON e XML. 


10.2 CONTENT NEGOTIATION 


Ter um método para cada formato de resposta diferente até funciona, o único 
problema é que você vai acabar com códigos repetidos. Lembre-se de que o 
único ponto que vai mudar é a representação do retorno; a lógica para recu- 
perar o dado vai ser a mesma. Vamos tentar resolver este problema. 
Primeiro, precisamos deixar apenas um método, respondendo dois for- 


matos: 


@GET 
@Produces ({MediaType.APPLICATION_JSON, 
MediaType. APPLICATION_XML}) 
public List<Book> lastBooksJson() { 
return bookDAO. lastReleases(); 
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O ponto agora é: quando um cliente fizer o request para a URL 
/services/books, qual formato vamos retornar? Essa é a parte interes- 
sante, o protocolo HTTP já fornece um jeito de lidar com esse problema! Ele 
permite que o cliente indique qual o formato de resposta que ele prefere. 

Veja um exemplo de requisição usando o curl: 


curl -H "Accept:application/json" -X GET 
"http://localhost :8080/casadocodigo/services/books" 


curl -H "Accept:application/xml" -X GET 
"http://localhost :8080/casadocodigo/services/books" 


No primeiro exemplo, fizemos uma requisição indicando que desejamos 
o retorno no formato application/json. Isso é feito por meio do cabe- 
çalho Accept. Perceba que no segundo já indicamos que queremos o XML 
como formato. Essa técnica é conhecida como Content Negotiation, e é muito 
utilizada em integrações baseadas no HT'TP, também conhecida como REST. 

Lembre-se de que REST é o conceito sobre o qual o JAX-RS é fundamen- 
tado. Caso seja necessário que todos os métodos do Resource suportem os 
dois formatos de resposta, podemos adicionar a annotation @Produces em 
cima da classe. 


OPath("books'!) 

OStateful 

@Produces (fMediaType. APPLICATION JSON, 
MediaType.APPLICATION XMLJ) 

public class BooksResource { 


10.3 SIMULANDO UM CLIENTE PARA O NOSSO SERVIÇO 


Para ficar mais próximo ainda da realidade, vamos criar uma aplicação cliente 
para consumir nosso serviço. Não precisamos de muito, simplesmente crie 
um novo Maven project no seu Eclipse. Os detalhes da criação ficam por sua 
conta, leitor. 

Vamos por uma classe que simula o consumo da listagem dos livros. 
Lembre-se de manter o servidor rodando. 
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package br.com.casadocodigo.loja.client; 
//imports 
public class BookList { 


public static void main(String[] args) 1 
Client client = ClientBuilder .newClient (); 
Response response = client.target( 
"http://localhost :8080/casadocodigo/services/books") 
. request (MediaType.APPLICATION_JSON) .get(); 


System. out .println(response.readEntity(String.class)) ; 


Perceba que usamos a API do JAX-RS para fazer as requisições. Inclu- 
sive, já tínhamos utilizado essa API quando integramos com o validador de 
pagamentos externos. Essa API foi uma grande adição que foi feita na especi- 
ficação, não precisamos mais ficar buscando entre várias opções que existiam. 
Fazemos a requisição especificando o tipo de retorno esperado, nesse caso o 
application/json. Fique à vontade para trocar por outros media types. 





Um outro ponto importante é o método readEntity. Ele espera que 
passemos o tipo que deverá ser usado para desserializar o JSON. No nosso 
caso, só foi necessário imprimir no console, mas você poderia ter criado o 
seu tipo para representar a lista de livros. 

Lembre-se de que, nesse momento, você não está dentro do servidor, e 
sim ao lado do cliente; portanto, não temos acesso a nenhuma classe que já 
foi criada. 

Veja a seguir um esboço do código que você poderia criar no lado do 
cliente: 


ClientBook[] books = response.readEntity (ClientBook[] .class); 


Lembre-se sempre de que a classe ClientBook teria de mapear todas 
as informações recebidas do servidor. Para que esse código funcione, preci- 
samos adicionar as dependências da implementação do JAX-RS, no caso, o 
RestEasy. 
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<dependencies> 
<dependency> 
<groupId>org. jboss.resteasy</groupId> 
<artifactId>resteasy-client</artifactId> 
<version>3.0.11.Final</version> 
</dependency> 


<dependency> 
<groupId>org. jboss.resteasy</groupId> 
<artifactId>resteasy-jackson-provider</artifactId> 
<version>2.3.4.Final</version> 

</dependency> 


</dependencies> 


Pronto, com isso conseguimos consumir o serviço no estilo REST que está 
exposto na nossa aplicação. Fique à vontade para ir além e tentar expor novos 


serviços. 





ESPECIFICANDO O TIPO DE RETORNO NA URL 


O RestEasy provê uma facilidade para que possamos especificar 
o formato de retorno do servidor. Basta que você adicione um 


context-param a mais no web.xml. 


<context-param> 
<param-name>resteasy.media.type.mappings</param-name> 
<param-value> 
json : application/json, xml : application/xml 
</param-value> 
</context-param> 


Agora você pode ir no navegado e, por exemplo, acessar o endereço 
http://localhost:8080/casadocodigo/services/books.json. 
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10.4 CONCLUSÃO 


Neste capítulo, foi abordado um tema que está em evidência: integração de 
sistemas via REST. Suportar o Content Negotiation é fundamental para você 
dar flexibilidade às aplicações clientes sobre qual formato elas preferem. Ou- 
tro ponto importante foi o uso da annotation @@Produces, pois, por meio 
dela, você vai informar quais são os tipos de retorno suportados por seu ser- 
viço. 

No próximo capítulo, trabalharemos para fechar uns pequenos detalhes 
relativos ao fechamento de uma compra. Por exemplo, é necessário que um 
e-mail seja enviado para notificar o nosso cliente! Como este capítulo foi até 
curto, não durma no ponto e continue a sua jornada. 
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CAPITULO 11 


Mais de processamento 
assincrono com JMS 


Nosso processo de compra já esta bem completo, até tratamos de outros tó- 
picos nos últimos dois capítulos. Só que, para o fechamento da compra ficar 
ainda mais próximo com o do site da Casa do Código, faltou mandarmos um 
e-mail de finalização de compra e simularmos o pedido da geração de nota 
fiscal. 


11.1 ENVIANDO O E-MAIL DE FINALIZAÇÃO 


Vamos começar pelo envio do e-mail. A lógica não tem nada de complicado: 
assim que o valor da nossa compra for autorizado, precisamos enviar um e- 
mail para o usuário que solicitou o pedido. 
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@Path ("payment") 
public class PaymentResource { 
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private 


static ExecutorService executor = 


Executors.newFixedThreadPool (50) ; 


@Context 


private 
@Inject 
private 
@Inject 
private 
@Inject 
private 


@POST 


ServletContext ctx; 


CheckoutDAO checkoutDao; 


PaymentGateway paymentGateway; 


MailSender mailSender; 


public void pay(@Suspended final AsyncResponse ar, 


@QueryParam("uuid") String uuid) { 


String contextPath = ctx.getContextPath() ; 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 


executor.submit(() -> { 


BigDecimal total = checkout. getValue(); 


try É 
paymentGateway.pay (total); 


String mailBody = "Nova compra. Seu código 

de acompanhamento é "+checkout.getUuid(); 

mailSender.send("comprastcasadocodigo. com.br", 
checkout .getBuyer () .gete-mail(), 
"Nova compra", 


mailBody) ; 
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} 


Para mantermos a clareza do nosso código, já isolamos o código de envio 
de e-mail em uma classe chamada MailSender. 


package br.com.casadocodigo.loja.infra; 
//infra 


@ApplicationScoped 
public class MailSender { 


public void send(String from,String to,String subject, 
String body){ 
//precisamos enviar o e-mail 


Especificação JavaMail 


Como ja estamos fazendo no decorrer do livro, vamos usar mais uma 
especificação para resolver o nosso problema. A JavaMail define tudo o que 
precisamos quando o assunto é envio de e-mail, e é justamente ela que será 
usada pela nossa classe MailSender. 

Como estamos dentro de um servidor de aplicação, nosso único trabalho 
é configurar o disparo do e-mail. Porém, antes de entrar na configuração 
específica do servidor, vamos analisar como ficaria o nosso código de envio 


em si. 


package br.com.casadocodigo.loja. infra; 


import javax.annotation.Resource; 

import javax.enterprise.context.ApplicationScoped; 
import javax.mail.Message; 

import javax.mail.MessagingException; 

import javax.mail.Session; 

import javax.mail.Transport; 
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import javax.mail.internet.InternetAddress; 


import javax.mail.internet .MimeMessage; 


@ApplicationScoped 


public class MailSender { 


ver. 


@Resource(mappedName = "java: jboss/mail/gmail") 
private Session session; 


public void send(String from,String to,String subject, 

String body) { 

Message mimeMessage = new MimeMessage(session) ; 

try + 
mimeMessage.setRecipients(javax.mail.Message 

.RecipientType.TO, InternetAddress.parse(to)); 

mimeMessage.setFrom(new InternetAddress (from) ); 
mimeMessage.setSubject ("Sua compra foi registrada"); 
mimeMessage.setContent (body, text/html"); 


Transport . send (mimeMessage) ; 
} catch (MessagingException e) { 
throw new RuntimeException(e); 


Respire um pouco e vamos dissecar o código que acabamos de escre- 


Perceba que a montagem do e-mail gira em torno do objeto do tipo 


MimeMessage. A partir dele, invocamos todos os métodos necessários para 


construir o e-mail: 
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e setRecipients - usamos para definir quem vai receber os e-mails; 
e setFrom-— define quem está enviando o e-mail; 


e setSubject — define o assunto do e-mail; 





e setContent - o corpo do e-mail em si. No nosso exemplo, informa- 


mos que estamos enviando um e-mail em HTML. 
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O método send da classe Transport é usado para efetivamente dis- 
parar o e-mail. Para concluir, só falta decifrar o objeto do tipo Session, 
que recebemos injetado associado um nome da JNDI. Esse objeto representa 
basicamente toda nossa configuração de envio de e-mail. 

É dentro dele que estão guardadas informações como: 


e Login e senha de acesso ao servidor de e-mail; 
e Endereço do servidor de e-mail, por exemplo, smtp.gmail.com; 
* Estilo de comunicação, se vai ser criptografado ou não. 


Para que a injeção deste objeto funcione, é preciso adicionar algu- 
mas configurações no arquivo standalone-full.xml, que está em 
caminhoInstalacaoWildFly/standalone/configuration. Para 
que não seja necessário navegar por todo sistema de arquivos, podemos aces- 
sar o arquivo por meio do próprio Eclipse. 


POR WAG 2 vv Rtannad Danunlish 


WildFly 8.x Runtime - 1 modules | 
Press 'F6' for Focus. 


¥ (= Configuration File ${jboss_config_dir} 


x) standalone-full.xmi 


> (=> Server Details 
> X| XML Configuration 
Q) JMXIDisconnected] 


Fig. 11.1: Arquivo de configuração pelo Eclispe 


É importante ressaltar que essa parte da configuração é específica do 
WildFly. Dentro do arquivo, procure pelo subsytem associado ao names- 
pace jboss:domain:mail:2.0. 


<subsystem xmlns="urn: jboss:domain:mail:2.0"> 
<mail-session name="default" 
jndi-name="java: jboss/mail/Default"> 
<smtp-server outbound-socket-binding-ref="mail-smtp"/> 
</mail-session> 
</subsystem> 
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Perceba que o próprio WildFly já possui uma configuração padrão para 
envio de e-mail. Logo, é necessário adicionarmos a nossa. 


<subsystem xmlns="urn: jboss:domain:mail:2.0"> 
<mail-session name="default" 
jndi-name="java: jboss/mail/Default"> 
<smtp-server outbound-socket-binding-ref="mail-smtp"/> 
</mail-session> 
<mail-session name="gmail" 
jndi-name="java: jboss/mail/gmail"> 
<smtp-server 
outbound-socket-binding-ref="mail-smtp-gmail" 
ssl="true" username="seuUserName" 
password="seuPassword"/> 
</mail-session> 
</subsystem> 


Estamos fazendo a configuração baseada no Gmail, portanto, além de 
passar nosso usuário e senha, somos obrigados a informar que toda comu- 
nicação será feita de maneira criptografada. É exatamente por isso que adici- 
onamos o atributo ssl. 

Lembre-se de que essas configurações podem mudar em função do ser- 
viço de e-mail que estiver usando, mas a tendência é que o nosso exemplo seja 
suficiente para a maioria dos casos. 

Outro ponto importante a se notar é o atributo jndi-name da tag 
mail-session. O valor passado foi justamente o mesmo que o referenciado 


por meio do nosso código. 


CApplicationScoped 
public class MailSender { 


@Resource(name = "java:jboss/mail/gmail") 
private Session session; 


A annotation @Resource serve, geralmente, para demarcar um ponto 
de injeção, assim como a @Inject. A tendência é que, cada vez mais, pas- 


230 


Casa do Cédigo Capítulo 11. Mais de processamento assíncrono com JMS 





semos a usara @Inject. O problema é que ainda vamos ter os casos em 
que a injeção vem de recursos mapeados via JNDI, e é justamente para essas 
situações que você usará a @Resource. 

Para fechar a configuração do e-mail, vamos voltar rapidamente para o 
arquivo standalone-full.xml. Natag mail-server, faltou analisar- 
mos o atributo outbound-socket-binding-ref. Ele faz referência ao 
pedaço da configuração onde especificamos detalhes como endereço e porta. 
Essa configuração é feita na seção socket -binding-group. 


<socket-binding-group ...> 
<socket-binding .../> 


<outbound-socket-binding name="mail-smtp"> 
<remote-destination host="localhost" port="25"/> 
</outbound-socket-binding> 


<outbound-socket-binding name="mail-smtp-gmail"> 
<remote-destination host="smtp.gmail.com" port="465"/> 
</outbound-socket-binding> 
</socket-binding-group> 


Além das que já existem, adicionamos mais uma tag 
outbound-socket-binding para especificar um endereço externo 
que o WildFly deverá usar. O valor do atributo name é exatamente o mesmo 
do atributo outbound-socket-binding-ref 

Agora, caso você feche uma compra, um e-mail já será disparado para o 
usuário utilizado no processo. Tome só cuidado para não usar um e-mail de 
mentira, e não ver o e-mail sendo entregue na sua caixa de entrada. 
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Java EE 7 E CONFIGURAÇÕES INDEPENDENTES DO SERVIDOR 


Visando, cada vez mais, deixar as configurações independentes no 
servidor, a partir do Java EE 7 foi criada uma annotation chamada 
MailSessionDefinition. Configurar um envio de e-mail, pelo me- 





nos em tese, deveria ser resumido a criar uma classe no sistema e utilizar 
essa annotation. 


@MailSessionDefinition(name = ''java:jboss/mail/gmail", 
host = "smtp.gmail.com", 
user="user", 
password="password", 
transportProtocol = "smtps", 
from="test@gmail.com", 
properties = { 
"mail.smtp.port=465" 
}) 


public class MailConfiguration { 


Perceba que fizemos quase todo o processo baseado em atributos ja 
definidos na annotation. Só a porta do servidor que precisou ser especi- 
ficada por meio de uma propriedade extra. 

O problema é que essa configuração, pelo menos no WildFly 8.2, 
ainda não funciona corretamente e, por isso, optamos por realizar a con- 
figuração baseada em arquivos específicos do servidor. 











11.2 UM POUCO MAIS SOBRE PROCESSAMENTO ASSÍN- 
CRONO 

No capítulo 8, no qual começamos a concluir o fechamento da compra, usa- 

mos o objeto do tipo AsyncResponse para permitir que o servidor não 


ficasse com a thread que atende o request travada enquanto estávamos nos 
comunicando com a outra aplicação. 
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Aqui devemos prestar atenção em um detalhe. Do ponto de vista do usuá- 
rio da Casa do Código, o processamento continuou síncrono, já que ele teve 
de ficar esperando pela resposta enquanto nosso processo estava trabalhando. 
Agora, do ponto de vista do servidor, o processamento foi assíncrono, já que 
a thread que atende o request foi liberada e, só quando a integração foi finali- 
zada, ela foi notificada para gerar a devida resposta para o cliente. 

Além de já esperar pela integração com o sistema de validação de paga- 
mento, o nosso usuário agora ainda está esperando pelo envio do e-mail e, 
também vai ser obrigado a esperar pela comunicação do sistema que gera a 
nota fiscal. Vamos ver como ficaria o nosso código agora: 


OPath ("payment") 
public class PaymentResource { 


@Inject 

private MailSender mailSender; 

@Inject 

private InvoiceGenerator invoiceGenerator; 


@POST 
public void pay(@Suspended final AsyncResponse ar, 


@QueryParam("uuid") String uuid) { 


String contextPath = ctx.getContextPath(); 
Checkout checkout = checkoutDao.findByUuid (uuid); 


executor.submit(() -> { 
BigDecimal total = checkout.getValue(); 


try É 
paymentGateway.pay (total); 


String mailBody = "Nova compra. 

Seu código de acompanhamento é "+ 

checkout.getUuid(); mailSender 
.send("compras@casadocodigo.com.br", 
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checkout. getBuyer() .gete-mail(), 
"Nova compra", mailBody) ; 


invoiceGenerator. invoiceFor (checkout); 


Para nao perdermos a linha de pensamento, vamos analisar a classe 
InvoiceGenerator só no fim do capítulo. O problema desse fluxo é que 
apenas a validação do valor é obrigatória para liberar a compra; as outras 
duas operações podem ser feitas sem que o nosso usuário fique esperando 
pelo retorno. 

Para resolver este problema, em vez de realizar a lógica de maneira sín- 
crona, podemos, mais uma vez, partir para uma abordagem assíncrona. Em 
vez de travar o código esperando pelo envio do e-mail e geração da nota fis- 
cal, simplesmente emitimos uma mensagem no sistema informando que uma 
nova compra acabou de ser aprovada, o tratamento fica para depois. 


Vamos dar uma olhada em um esboço de código: 


@POST 
public void pay(@Suspended final AsyncResponse ar, 
@QueryParam("uuid") String uuid) { 


String contextPath = ctx.getContextPath() ; 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 


executor.submit(() -> { 
BigDecimal total = checkout.getValue(); 
try A 


paymentGateway .pay (total); 
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//emitimos um comunicado de nova compra 


A ideia é que possamos enviar uma nova mensagem, e que as classes res- 
ponsaveis tratem isso de maneira assincrona. 


11.3 UTILIZANDO O JMS PARA MENSAGERIA 


A especificação JMS (Java Message Service) nos possibilita justamente imple- 
mentar essa forma de trabalhar. Basicamente, precisamos enviar uma men- 
sagem que chegue para os objetos responsáveis por tratar os eventos de uma 
nova compra. No nosso caso, é necessário enviar o e-mail e solicitar a geração 
da nota fiscal. 


Vamos começar pelo código de envio de mensagem: 


OPath ("payment") 
public class PaymentResource { 


@Inject 
private JMSContext jmsContext ; 


@Resource(lookup = "java:/jms/topics/checkoutsTopic") 
private Destination checkoutsTopic; 


@POST 

public void pay(@Suspended final AsyncResponse ar, 
@QueryParam("uuid") String uuid) { 
String contextPath = ctx.getContextPath(); 
Checkout checkout = checkoutDao.findByUuid(uuid) ; 
JMSProducer producer = jmsContext.createProducer (); 
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executor.submit(() -> { 
BigDecimal total = checkout.getValue() ; 


try É 
paymentGateway.pay (total); 


producer. send(checkoutsTopic, 
checkout. getUuid()); 


} catch (Exception exception) { 


H); 


Temos alguns pontos para analisar nesse código. O objeto do 
tipo JMSProducer é o responsável por enviar uma mensagem. Para 
efetivamente disparar a mensagem para o sistema, usamos o método 
send (destino, conteudo). 


Existem dois tipos de destino no JMS: 


e Quando a mensagem deve ser tratada apenas uma vez, usamos um des- 
tino conhecido como Fila; 


* Quando a mensagem pode ser tratada por vários objetos, usamos um 
destino conhecido como Tópico. 


Por exemplo, no nosso caso, é necessário que a mensagem do checkout 
seja tratada pelo objeto que envia e-mail e pelo gerador da nota fiscal, então, 
nesse caso usamos um tópico. 

Agora, caso tivéssemos optado por validar o pagamento enviando uma 
mensagem, seria necessário que tal mensagem fosse tratada apenas uma vez 
e, para esse cenário, usar uma fila seria o ideal. 
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O destino no JMS é representado por meio de um objeto do tipo 
Destination. Assim como já fizemos quando foi necessário receber o con- 
texto de uso do e-mail, temos de utilizar a annotation @Resource, pois va- 
mos referenciar o tópico exposto na JNDI. 

Além do destino, somos obrigados a passar o conteúdo da mensagem. No 
nosso caso, optamos por passar o identificador da compra. Dessa forma, cada 
objeto responsável pelo tratamento de finalização da compra pode carregá-la 
e realizar sua lógica. 


OPath ("payment") 
public class PaymentResource { 


OGResource (name = "java:/jms/topics/checkoutsTopic") 
private Destination checkoutsTopic; 


Agora, só falta resolver o trecho de código responsável por criar um 
JMSProducer. 


@Inject 

private JMSContext jmsContext; 

@Resource(lookup = "java:/jms/topics/checkoutsTopic") 
private Destination checkoutsTopic; 


@POST 
public void pay(@Suspended final AsyncResponse ar, 
@QueryParam("uuid") String uuid) { 


JMSProducer producer = jmsContext.createProducer (); 


executor.submit(() -> { 
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O objeto do tipo JMSContext representa o elo de conexão entre a aplica- 
ção e a infraestrutura necessária para enviar as mensagens. É através dele que 
criamos um objeto do tipo JMSProducer. Para recebê-lo injetado, pode- 
mos usar diretamente a annotation @Inject. Todo servidor de aplicação é 
obrigado a disponibilizar uma implementação padrão da interface e deixá-la 
disponível. 


Configurando o tópico 


Para que a injeção do Destination funcione, é necessário que seja in- 
formado ao servidor que o tópico seja criado e exposto com determinado 
nome na JNDI. Ao contrário da configuração do DataSource e do e-mail, 
a configuração dos destinos do JMS, a partir do Java EE 7, pode ser feita inte- 
gralmente via annotations. 


package br.com.casadocodigo.loja.conf; 
import javax.jms.JMSDestinationDefinition; 


@JMSDestinationDefinition( 
name=""java:/jms/topics/checkoutsTopic", 


interfaceName = "javax.jms.Topic" 


) 


public class ConfigureJMSDestinations { 


Essa é a simplicidade que estamos buscando! Configurar um pedaço com- 
plexo do sistema de uma maneira extremamente simples. O atributo name 
recebe o nome que será exposto na JNDI. Já o atributo interfaceName re- 
cebe o nome completo da interface do JMS ligada a um tipo de destino. No 
nosso caso, passamos javax. jms.Topic, mas se fosse necessário trabalhar 
com uma fila, bastaria passar javax. jms . Queue. Ainda é possível, quando 
você tem vários destinos, configurar múltiplos destinos. 


@JMSDestinationDefinitions ({ 
@JMSDestinationDefinition ( 
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), 


@JMSDestinationDefinition( 


}) 


public class ConfigureJMSDestinations { 


Talvez cause uma certa estranheza criar uma classe completamente vazia. 
Aqui esbarramos em uma limitação da linguagem, já que a annotation sempre 
deve estar associada a um código Java. 


11.4 REGISTRANDO TRATADORES DE MENSAGENS COM 
MDBs 


Já adicionamos o suporte ao tratamento assíncrono de partes do processa- 
mento de uma nova compra. A única pergunta que ficou é: cada vez que chega 
uma nova compra mandamos uma mensagem, mas quem está tratando? Pre- 
cisamos associar objetos com o tópico especificado. 

Para fazermos isso, vamos recorrer de novo aos EJBs, só que agora a um 
tipo especial chamado de Message Driven Bean (MDB). É um EJB especial que 
pode ser associado a um destino e receber as mensagens que forem chegando. 
Vamos ver como ficaria para criar um MDB responsável por mandar o e-mail 


da compra. 


package br.com.casadocodigo.loja.listeners.checkout; 


import javax.ejb.ActivationConfigProperty; 
import javax.ejb.MessageDriven; 

import javax.inject.Inject; 

import javax. jms.Message; 

import javax. jms.MessageListener; 

import javax.jms.TextMessage; 
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import org.slf4j.Logger; 
import org.slf4j.LoggerFactory ; 


//outros imports 


@MessageDriven(activationConfig = { 
@ActivationConfigProperty ( 
propertyName = "destinationLookup", 
propertyValue = "java:/jms/topics/checkoutsTopic") 
}) 
public class SendCheckoute-mailListener 
implements MessageListener{ 


private Logger logger = LoggerFactory 
. get Logger (SendCheckoute-mailListener.class) ; 
@Inject 
private MailSender mailSender; 
@Inject 
private CheckoutDAO checkoutDao; 


@Override 
public void onMessage (Message message) { 
TextMessage text = (TextMessage) message; 
try { 
Checkout checkout = checkoutDao 
.findByUuid(text.getText()); 
String e-mailBody = "<html><body>Compra realizada 
com sucesso. 0 código de acompanhamento é " 
+ checkout.getUuid() + "</body></htm1>"; 


mailSender.send("compras@casadocodigo.com.br", 
checkout .getBuyer() .gete-mail(), 
"Sua compra foi registrada com sucesso", 
e-mailBody) ; 


} catch (Exception e) { 
logger.error("Problema no envio do e-mail",e); 
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Precisamos investir um tempo para entender partes deste código. Vamos 
começar pelo uso da annotation @MessageDriven. Ela é a responsável por 
informar ao servidor de aplicação que estamos criando um novo MDB. Sua 
configuração, porém, é meio complicada de olhar. 


@MessageDriven(activationConfig = { 
@ActivationConfigProperty ( 
propertyName = "destinationLookup", 
propertyValue = "java:/jms/topics/checkoutsTopic") 
+) 


Para dizer que queremos escutar as mensagens que fo- 
rem chegando no tópico que configuramos, precisamos usar 
a annotation @ActivationConfigProperty. Na ver- 
dade, o atributo activationConfig recebe um array de 
@ActivationConfigProperty. Por meio dessa annotation, vamos 
passando as informações necessárias. 





A lista de possíveis propriedades pode ser encontrada em http://docs. 
oracle.com/cd/E19798-01/821-1841/bnbpo/index.html. 











Para o nosso caso, precisamos da dest inat ionLookup para associar o 
nome da JNDI, onde será buscada a referência para o nosso tópico. É impor- 
tante ressaltar que essa propriedade é prevista na especificação; não impor- 
tando o servidor que você rode o código, tal configuração deve ser suportada. 


Além da annotation relativa ao MDB, também somos obrigados a imple- 





mentar a interface MessageListener, que define o método onMessage. É 
justamente ele que vai ser invocado toda vez que uma nova mensagem chegar. 


@Override 

public void onMessage(Message message) { 
TextMessage text = (TextMessage) message; 
try É 
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Checkout checkout = checkoutDao 
.findByUuid(text.getText()); 
String e-mailBody = "<html><body>Compra realizada 
com sucesso. 0 código de acompanhamento é " 
+ checkout .getUuid() + ''</body></html>"; 


mailSender.send("compras@casadocodigo.com.br", 
checkout .getBuyer() .gete-mail(), 
"Sua compra foi registrada com sucesso", 
e-mailBody) ; 


} catch (Exception e) { 
logger.error("Problema no envio do e-mail",e); 


Recebemos como argumento um objeto do tipo Message, que é a inter- 
face mãe de todas as possíveis mensagens do JMS. Como, na hora de mandar 
a mensagem, foi usado o código producer.send (checkoutsTopic, 
checkout.getUuid()), passando como segundo argumento uma 
String, é montado um objeto do tipo TextMessage. Como isso é garan- 
tido pela especificação, podemos simplesmente fazer o cast da mensagem 
que chega e recuperar a mensagem enviada. 


TextMessage text = (TextMessage) message; 


try É 
Checkout checkout = checkoutDao.findByUuid(text.getText()); 


Para completar o processo, podemos criar o MDB responsável por pedir 
a geração da nota fiscal da compra. 


package br.com.casadocodigo. loja. listeners.checkout; 
//imports 


@MessageDriven(activationConfig = { 
@ActivationConfigProperty ( 
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propertyName = "destinationLookup", 
propertyValue = 
"java: /jms/topics/checkoutsTopic") 
5) 
public class GenerateInvoiceListener 
implements MessageListener{ 


private Logger logger = LoggerFactory. 
getLogger (GenerateInvoiceListener.class) ; 

@Inject 

private InvoiceGenerator invoiceGenerator; 

@Inject 

private CheckoutDAO checkoutDao; 


@Override 
public void onMessage(Message message) { 
TextMessage text = (TextMessage) message; 
try £ 
Checkout checkout = checkoutDao 
.findByUuid(text.getText()); 
invoiceGenerator. invoiceFor (checkout); 
} catch (JMSException e) { 
logger.error("Problema na geracao 
da nota fiscal {}",e); 


O código em si não tem nada de novo. O leitor mais crítico deve até 
estar pensando: por que o e-mail e a nota fiscal não foram processados pelo 
mesmo MessageListener? O problema, nesse caso, de deixar toda a ló- 





gica no mesmo lugar, é que o mal funcionamento de uma pode influenciar 
na outra. Do jeito que fizemos, mesmo que ocorra um problema no envio do 
e-mail, a nota fiscal continua sendo gerada. 

Uma outra questão é que deixar muito código de processamento longo 
dentro do mesmo listener pode fazer com que o próprio listener 
vire um gargalo, e algumas mensagens comecem a dar timeout. Sempre tente 
deixá-los com o mínimo de responsabilidade possível, e altamente coesos. 
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Para que a classe InvoiceGenerator não fique obscura, vamos dar 
uma olhada nela: 


package br.com.casadocodigo.loja.services; 


//imports 
public class InvoiceGenerator { 


public void invoiceFor (Checkout checkout) 1 
Client client = ClientBuilder.newClient(); 
InvoiceData invoiceData = new InvoiceData(checkout) ; 
String uriToGenerateInvoice = 

"http: //book-payment .herokuapp.com/invoice"; 

Entity<InvoiceData> json = Entity.json(invoiceData) ; 
client .target (uriToGenerateInvoice). 
request ().post(json, String.class) ; 


Ela usa a API de cliente do JAX-RS para fazer uma requisição a um sistema 
externo, para solicitar a geração de uma nova nota fiscal. Além disso, usamos 
o objeto do tipo InvoiceData para passar as informações necessárias para 
a geração da nota fiscal. 


package br.com.casadocodigo.loja.models; 

import java.math.BigDecimal; 

import br.com.casadocodigo.loja.models.Checkout ; 
public class InvoiceData 


private BigDecimal value; 
private String buyere-mail; 


public InvoiceData(Checkout checkout) { 


this.value = checkout.getValue(); 
this.buyere-mail = checkout.getBuyer().gete-mail(); 
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public BigDecimal getValue() { 
return value; 


public String getBuyere-mail() { 
return buyere-mail; 


11.5 IMPLEMENTAÇÃO DO JMS UTILIZADA PELO WILD- 
FLY 


Todo serviço de mensageria é provido por um outro servidor, que geralmente 
é integrado no servidor de aplicação de modo que a aplicação possa tirar pro- 
veito. No caso do WildFly, é utilizado o HornetQ (http://hornetqg.jboss.org/) 


A ideia, como vimos no decorrer do capítulo, é tentar minimizar o aco- 
plamento com a implementação da especificação. De toda forma, é necessário 
entender quais implementações são usadas, já que você pode ser obrigado a 
recorrer a alguma configuração específica. 


11.6 CAUTELA NO USO DO CÓDIGO ASSÍNCRONO 


A execução de código de maneira assíncrona tende a elevar a capacidade de 
um sistema de escalar. Como passamos menos tempo para dar uma resposta, 
já que boa parte dela vai ser processada em outro momento, conseguimos 
atender mais requisições em um determinado intervalo de tempo. Entretanto, 
adicionamos uma certa complexidade no sistema, ponto que sempre deve ser 
pesado em qualquer decisão arquitetural. 

Uma dica deste autor é que você, na maioria das vezes, comece sempre 
pensando em um código mais simples, geralmente síncrono e, quando neces- 
sário, evolua para o código assíncrono. 
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11.7 CONCLUSÃO 


Este foi um capítulo um pouco mais denso! Enquanto a especificação relativa 
ao envio de e-mails é relativamente simples, a JMS é bem mais complicada. 
Lidar com código assíncrono sempre é um pouco mais complexo e exige mais 
da nossa atenção. 

É importante lembrar de que sempre que você estiver dentro de um ser- 
vidor de aplicação, um Message Driven Bean deve ser criado para conse- 


guir ser notificado de novas mensagens. Outro ponto importante é a inter- 





face MessageListener, que deve ser implementada para que o método 
onMessage possa ser chamado dentro do MDB. 

Minha dica é que você descanse um pouco a sua mente para poder pro- 
cessar tudo que estudamos. No próximo capítulo, vamos adicionar a parte de 


segurança e, mais uma vez, usaremos uma especificação do Java EE. 
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Protegendo a aplicação 


Até agora, todas as URLs do nosso sistema estão acessíveis por todos os usuá- 
rios. Algumas até são liberadas, como a que leva para a página inicial, que 
deve exibir todos os livros. Só que temos algumas URLs que necessitam de 
um usuário logado, como as que compõem a parte de administração da loja. 

Podemos até implementar toda essa parte de segurança na mão, mas, 
como já vem sendo feito no decorrer do livro, vamos usar uma especifica- 
ção do Java EE que define soluções para várias das necessidades que teremos. 
É bom sempre lembrar que implementar uma estratégia de segurança não é 
trivial. 

Além de forçar o login para algumas URLs, é necessário ter preocupação 
com pelo menos mais alguns itens, como: 


e Quais perfis podem acessar as URLs, também conhecido como autori- 
zação; 
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* URLs acessadas por vários perfis, mas com trechos de página restritos; 


e Fontes de dados diferentes para realização de login. 


12.1 DEFININDO AS REGRAS DE ACESSO COM O JAAS 


Java Authentication and Authorization Service (também conhecido como 
JAAS) é justamente a especificação do Java criada para tratar da parte de se- 
gurança em nossas aplicações. Inclusive, a especificação de Servlets também 
já é integrada a essa especificação. 

Basicamente, precisamos configurar alguns detalhes para que os endere- 
ços da nossa aplicação comecem a ficar protegidos. Boa parte dessa configu- 
ração é feita diretamente no arquivo web.xml. 


<web-app xmlns:xsi= 
"http://www.w3.0rg/2001/XMLSchema-instance" 


<security-constraint> 
<display-name>Administracao</display-name> 
<web-resource-collection> 
<web-resource-name> 
administracao 
</web-resource-name> 
<description> 
Urls que levam para paginas de administracao 
</description> 
<url-pattern>/livros/*</url-pattern> 
<http-method>GET</http-method> 
<http-method>POST</http-method> 
</web-resource-collection> 
<auth-constraint> 
<role-name>ADMIN</role-name> 
</auth-constraint> 
</security-constraint> 
<security-role> 
<role-name>ADMIN</role-name> 
</security-role> 


</web-app> 
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Sempre vamos trabalhar com o seguinte par: URLs e roles. Declarare- 
mos endereços que só podem ser acessados por certos usuários de determi- 
nados perfis, definidos no sistema. Para cada associação que for necessária, 
vamos declarar uma tag security-constraint e definir as regras. 

Vamos dar um zoom no conteúdo da tag, para deixar tudo completa- 


mente claro: 


<security-constraint> 
<display-name>Administracao</display-name> 
<web-resource-collection> 
<web-resource-name>administracao</web-resource-name> 
<description> 
Urls que levam para paginas de administracao 
</description> 
<url-pattern>/livros/*</url-pattern> 
<http-method>GET</http-method> 
<http-method>POST</http-method> 
</web-resource-collection> 
<auth-constraint> 
<role-name>ADMIN</role-name> 
</auth-constraint> 
</security-constraint> 





A tag web-resource-collection define os padrões de endereço que 
devem ser protegidos. No nosso caso, informamos que, para acessar qual- 
quer endereço que comece com /livros, o usuário deve estar logado. Além 
disso, informamos os verbos HT'TP associados ao acesso. Para completar, 
usamos a tag auth-constraint para indicar quais grupos, também co- 
nhecidos como roles, podem acessar os endereços protegidos. Dentro 





da tag web-resource-collection, você pode adicionar quantas tags 
url-pattern você desejar, tudo vai depender da aplicação. 

Caso você inicie o WildFly e tente acessar o endereço http://localhost: 
8080/casadocodigo/livros/form.xml, perceberá que é retornada uma página 
em branco, escrito Forbidden. Inclusive, se habilitar o Firebug ou o Chrome 
tools, vai perceber no console que o status retornado pelo servidor é 403, que 
indica justamente que você não tem autorização para acessar determinados 


recursos. 
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O © Yy View = =. Options: | Preserve log | |Disable cache 
XHR Script Style Images Media 
Name Method Status 
Path Text 
=| form.xhtml 403 
| GET 
== /casadocodigo/livros Forbidden 


Fig. 12.1: Acesso negado 


12.2 CONFIGURANDO O FORMULÁRIO DE LOGIN 


Já começamos falando sobre os perfis autorizados para acessar determinados 
recursos, mas como isso ia ser possível se nem demos a chance de o usuário 
se logar? Para explicar para o JAAS que necessitamos que o usuário primeiro 
se autentique, para depois tentar acesso a qualquer recurso, vamos declarar a 
tag login-configno web.xml. 


<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 


<login-config> 
<auth-method>FORM</auth-method> 
<form-login-config> 
<form-login-page> 
/users/login. xhtml 
</form-login-page> 
<form-error-page> 
/users/login. xhtml 
</form-error-page> 
</form-login-config> 
</login-config> 


<security-constraint> 


</security-constraint> 
</web-app> 
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A tag auth-method indica que queremos trabalhar com um formu- 
lário de login, onde o usuário vai passar o seu login e sua senha. Já a tag 
form-login-config serve para indicarmos qual deve ser a página de lo- 
gin e qual deve ser a página quando acontecer alguma falha nele. 

Para o nosso caso, apontamos as duas para a mesma página. Para 
que essa configuração funcione, precisamos criar a página de login em 
webapp/users/login.xhtml. 


<html xmlns="http://www.w3.org/1999/xhtm1"> 
<body> 
<form method="POST" 
action="${request.getContextPath()}/j_security_check"> 
<div> 
<label for="e-mail">e-mail</label> 
<input type="text" 
name=""j_username" value="${param. j_username}" 
id="e-mail"/> 
</div> 
<div> 
<label for="password">Senha</label> 
<input type="password" name="j_password" 
id="password"/> 
</div> 


<input type="submit" value="Login" /> 
</form> 
</body> 
</html> 


O leitor mais atento deve ter estranhado o endereço utilizado na tag 
action, assim como os nomes dos inputs. O ponto é que a especifica- 
ção de Servlets já fornece a integração de autenticação baseado no JAAS, o 
servidor só precisa saber qual é o endereço que, quando acessado, deve dar 
início ao processo de autenticação. 

Além disso, ele também precisa saber quais parâmetros indicam o login 
e a senha passados pelo usuário. Todos esses valores são definidos pela espe- 
cificação de Servlets, e não podem ser alterados. No fundo, também não faz 
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sentido querer mudar, já que isso não influencia em nada o funcionamento 
da nossa aplicação. 

O problema agora é que sempre que tentamos realizar um login na apli- 
cação, somos barrados. Pensando um pouco melhor, faz até sentido, pois não 
adicionamos nenhuma senha para os nossos compradores da loja e também 
não cadastramos nenhum novo usuário com login, senha e perfis associados. 


Incrementando o domínio para refletir o modelo de segurança 


O domínio da nossa aplicação ainda não foi atualizado para refletir o 
nosso novo esquema de segurança. O primeiro passo é justamente associar o 
usuário com os seus respectivos perfis. 


CEntity 
public class SystemUser { 


@ManyToMany (fetch = FetchType.EAGER) 
private List<SystemRole> roles = new ArrayList<>(); 


//getters e setters 


Agora, precisamos da classe SystemRole: 


package br.com.casadocodigo.loja.models; 


import javax.persistence.Entity; 
import javax.persistence.Id; 


@Entity 
public class SystemRole { 


@Id 
private String name; 


@Deprecated //apenas para os frameworks 


public SystemRole() { 
} 
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public SystemRole(String name) { 
this.name = name; 


//getters e setters 


Quando você subir a aplicação, por conta da configuração do Hibernate, 
as nossas tabelas já serão atualizadas. Agora podemos cadastrar um novo 
usuário com o perfil de administração. Podemos inserir alguns dados direta- 
mente pelo console do MySQL. 


insert into SystemUser (e-mail,password) 
values (’admin@casadocodigo.com.br’, 
insert into SystemRole values (? ADMIN”); 


insert into SystemUser SystemRole values 
(id gerado para o admin,?ADMIN?); 


A senha usada foi gerada a partir do seguinte trecho de código: 


package br.com.casadocodigo.loja.security; 
import org.jboss.security.Base64Encoder; 
public class PassGenerator { 


public static void main(String[] args) throws Exception { 
Base64Encoder.main(new String[]{"123456","SHA-256"}) ; 


A classe Base64Enconder é fornecida pelo próprio WildFly, e é útil 





para representar a senha usando a Base64. Além disso, após o texto ter sido 
encodado, é aplicado o algoritmo de hash SHA-256. 

Mesmo com os dados cadastrados, ainda não conseguimos efetuar o login 
dentro da nossa aplicação. Afinal de contas, onde foi que explicamos para o 
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servidor da aplicação a maneira como queremos buscar os dados de login e 
senha passados no formulário? 


12.3 CONFIGURANDO O LOGINMODULE DO JAAS 


Para que o nosso login seja efetuado, é preciso ter uma classe que consiga re- 
cuperar os dados passados pelo usuário e, dessa forma, verifique se realmente 
esse usuário existe no banco de dados. O JAAS define uma interface chamada 
LoginModule, que deve ser implementada pela aplicação, justamente com o 
propósito necessitado. 

Para a nossa sorte, estamos dentro de um servidor de aplicação, e todos 
eles já fornecem implementações prontas dessa interface, de modo a facilitar 
o nosso trabalho. 


Configurando um LoginModule no WildFly 


Para adicionarmos o módulo de login no WildFly, precisamos, mais uma 
vez, alterar o arquivo standalone-full.xml. Lembre-se de acessá-lo por 
meio do próprio Eclipse, para não precisar navegar por todo sistema de ar- 
quivos. 

No arquivo de configuração, temos um módulo associado ao namespace 
urn: jboss:domain:security:1.2. Perceba que, dentro dele, já existem 


alguns domínios de segurança compostos por um ou mais login modules. 


<security-domains> 
<security-domain name="other" cache-type="default"> 
<authentication> 
<login-module code="Remoting" flag="optional"> 
<module-option name="password-stacking" 
value="useFirstPass"/> 
</login-module> 
<login-module code="RealmDirect" flag="required"> 
<module-option name="password-stacking" 
value="useFirstPass"/> 
</login-module> 
</authentication> 
</security-domain> 
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<security-domain name="jboss-web-policy" 
cache-type="default"> 
<authorization> 
<policy-module code="Delegating" flag="required"/> 
</authorization> 


</security-domain> 


</security-domains> 


Os que já estão declarados são usados internamente pelo WildFly. Por 
exemplo, o security-domain de nome other é utilizado interna- 
mente para verificar as credenciais de acesso das aplicações para EJBs re- 
motos. Eles até podem combinar mais de um login module. Ainda no 
security-domain usado pelos EJBs, existem dois módulos de login. Para a 
maioria das aplicações, apenas um módulo já é suficiente, e esse é justamente 
O Nosso caso. 

Vamos adicionar mais um security-domain na lista já existente no 


WildFly. 


<security-domains> 


<security-domain name="database-login" 
cache-type="default"> 
<authentication> 
<login-module code="Database" flag="required"> 
<module-option name="dsJndiName" 
value="java: jboss/datasources/ 
casadocodigoDS"/> 


<module-option name="principalsQuery" 
value="select password from SystemUser 
where e-mail=?"/> 


<module-option name="rolesQuery" 


value="select roles_name, ’Roles’ 
from SystemUser_SystemRole as 
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user_roles inner join SystemUser as 
su on su.id = user_roles.SystemUser_id 
where su.e-mail = ?"/> 


<module-option name="hashAlgorithm" 
value="SHA-256"/> 


<module-option name="hashEncoding" 
value="base64"/> 


</login-module> 
</authentication> 
</security-domain> 
</security-domains> 


Vamos respirar um pouco e entender toda essa configuração. O primeiro 
detalhe é que usamos o valor Database no atributo code. O WildFly já 
oferece várias implementações da interface LoginModule e, quando quere- 
mos usar uma delas, fazemos a referência através de uma chave já definida. 
Seguem alguns exemplos: 


e Database- 


org.jboss.security.auth.spi.DatabaseServerLogin Module 
e Ldap- 
org.jboss.security.auth.spi.LdapLoginModule 
* Simple- 
org.jboss.security.auth.spi.SimpleServerLoginModule 


e PropertiesUsers — 


org.jboss.security.auth.spi.PropertiesUsersLoginModule 





POSSIBILIDADES DO MÓDULO DE SEGURANÇA 


A lista completa pode ser encontrada em https://docs.jboss.org/ 
author/display/WFLY8/Security+subsystem+configuration. 
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Outro detalhe importante é o atributo flag. Atribuimos o valor 
required para dizer que nosso usuário, obrigatoriamente, tem de passar por 
esse módulo para ter acesso à parte protegida da aplicação. 

Para fechar essa parte, é necessário discutir as opções que foram passadas 
para o módulo de login. A maneira mais simples de justificá-las é dando uma 
olhada no código-fonte da classe que será usada pelo nosso módulo. 


public class DatabaseServerLoginModule extends 
UsernamePasswordLoginModule 


public void initialize(Subject subject, CallbackHandler 
callbackHandler, Map<String,?> sharedState, 
Map<String,?> options) 


addValidOptions(ALL VALID OPTIONS); 
super. initialize(subject, callbackHandler, 
sharedState, options); 
dsJndiName = (String) options.get(DS JNDI NAME); 
if( dsJndiName == null ) 
dsJndiName = "java:/DefaultDS"; 
Object tmp = options.get(PRINCIPALS_QUERY) ; 
if( tmp != null ) 
principalsQuery = tmp.toString(); 
tmp = options.get (ROLES QUERY); 


Desse código todo, você precisa perceber apenas um detalhe: o método 
initialize recebe, em dos argumentos, um objeto do tipo Map por meio 
da variável options. Esse mapa é montado justamente a partir das opções 
que passamos na configuração em XML. O método initialize é definido 
pela especificação, e sempre é chamado para inicializar os valores necessários 
para cada LoginModule. 

Agora fica mais claro o motivo das opções que passamos no arquivo de 
configuração serem no estilo chave -> valor. Também que os nomes ali usados 


257 


12.3. Configurando o LoginModule do JAAS Casa do Cédigo 





são específicos do container que você estiver usando. 


<login-module code="Database" flag="required"> 
<module-option name="dsJndiName" 
value="java: jboss/datasources/casadocodigoDS"/> 


<module-option name="principalsQuery" 
value="select password from SystemUser 
where e-mail=?"/> 


<module-option name="rolesQuery" 
value="select roles_name, ’Roles’ 
from SystemUser_SystemRole as user_roles 
inner join SystemUser as su 
on su.id = user_roles.SystemUser_id 
where su.e-mail = ?"/> 


<module-option name="hashAlgorithm" 
value="SHA-256"/> 


<module-option name="hashEncoding" 
value="base64"/> 


</login-module> 


Agora, vamos dissecar um pouco as opções para entender exatamente o 
que significa cada uma: 


e dsJndiName - nome JNDI do nosso datasource, que já está confi- 
gurado. 


e principalsQuery - SQL necessário para recuperar um usuário ba- 
seado no login. No nosso caso, foi utilizado o e-mail. 


e rolesQuery - SQL necessário para recuperar os perfis de determi- 
nado usuário, baseado no seu login. 


e hashAlgorithm - algoritmo de hash que vai ser aplicado na senha 
para fazer a checagem no banco. 
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e hashEncoding - algoritmo usado para realizar o encoding da senha. 


Um detalhe que pode chamar atenção é o uso da coluna inexistente 
Roles na query que recupera os perfis. Aqui é apenas um detalhe mais téc- 
nico imposto pelo próprio JAAS. Dentro da especificação, tanto o usuário 
logado quanto os perfis associados a ele são representados como classes que 
implementam a interface Principal. 

O JAAS nos permite que agrupemos esses objeto em grupos de acesso. 
Veja alguns exemplos: 


e Usuário administrador que pode fazer tudo no sistema; 


e Usuário administrador que não pode deletar livros. 


Esses grupos são representados por implementações da interface Group. 
O WildFly lhe obriga a retornar na query que carrega os perfis, a quais grupos 
cada uma delas pertence. Caso a aplicação não faça uso dos grupos, devemos 
especificar uma espécie de grupo padrão, e é exatamente por isso que adicio- 
namos a coluna Roles. Jaa palavra tem de ser Roles, por ser uma exigência 


do WildFly. 


Associando a aplicação com um security domain 


Mesmo configurando o novo security-domain no WildFly, ainda não 
conseguimos efetuar o login dentro da aplicação. O último passo é justa- 
mente informar que nossa aplicação precisa fazer uso do domínio configu- 
rado. Para que isso aconteça, é necessário que o projeto crie um arquivo cha- 





mado jboss-web.xml, na pasta WEB-INF. 


<?aml version="1.0" encoding="UTF-8"?> 

<jboss-web> 
<security-domain>database-login</security-domain> 

</jboss-web> 


Lembre-se de que esse é um arquivo específico do WildFly! 

Pronto, agora já conseguimos efetuar o login da nossa aplicação. Tente 
acessar os endereços que estão protegidos e perceba que tudo vai funcionar 
como deveria. 
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Caso você cadastre outros usuários com outros perfis, configure uma pá- 
gina de erro com o status 403, no web.xml. Dessa forma, quando alguém 
tentar acessar um endereço não permitido, será levado para uma página in- 
formativa. 

Outra funcionalidade que você pode implementar é a de cadastro de no- 
vos usuários administradores. Lembre-se apenas de proteger o seu acesso! 


12.4 EXIBINDO O USUÁRIO LOGADO E ESCONDENDO 
TRECHOS DA PÁGINA 


Um detalhe comum é exibir o login do usuário nas páginas que ele acessa 
dentro do sistema. Por exemplo, queremos exibir o e-mail dele na página de 
listagem de livros. 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets"> 
<h: body> 
<div> 
Seja bem vindo, e-mailDoUsuario 
</div> 


</h: body> 
</html> 


O problema é: de onde vem essa informação? Na verdade temos mais 
coisas a pensar. Perceba que toda configuração que fizemos relativa ao JAAS 
não envolveu, em nenhum momento, as classes do nosso sistema. Tudo foi 
realizado usando os arquivos de configuração do servidor da aplicação. 

O máximo de informação que conseguimos recuperar do usuário logado 
é o login passado por ele que, nesse caso, é justamente o e-mail. Para recuperar 
o objeto que contém essa informação, podemos usar diretamente o request. 


<div> 
Seja bem vindo, (request .getUserPrincipal() .getName () + 
</div> 
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Caso seja apenas essa a informação que você precisa do seu usuário lo- 
gado, esse código é mais do que suficiente. O problema é que quase nunca 
você quer apenas isso. Muitas vezes vamos querer saber mais informações, 
como o nome do usuário, data de último login etc. 

Para conseguirmos fazer isso, vamos precisar carregar as informações 
pertinentes a nossa entidade da aplicação, nesse caso a SystemUser. O me- 
lhor jeito de fazer isso é criando uma nova classe na aplicação e isolando essa 
lógica lá dentro. 


package br.com.casadocodigo.loja.security; 
//imports 


@Model 
public class CurrentUser { 


@Inject 

private HttpServletRequest request; 
@Inject 

private SecurityDAO securityDAO; 
private SystemUser systemUser; 


public SystemUser get(){ 
return this.systemUser; 


@PostConstruct 
private void loadSystemUser() 1 
Principal principal = request.getUserPrincipal (); 
if (principal != null) { 
this.systemUser = securityDAO 
. loadUserByUsername (principal .getName()); 


Lembre-se de que a annotation @Mode1 já informa ao CDI que os objetos 
criados a partir desta classe devem viver no escopo de uma requisição web, e 
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que também devem ficar expostos na expression language. O objeto do tipo 
Principal representa o usuário que acabou de se logar no sistema e, como 
já vimos, recuperamo-lo por meio do request. O método getName retorna 
justamente o login do usuário. 

Colocamos o código de carregamento dentro de um método anotado com 
@PostConstruct. Perceba que só carregamos de fato o usuário, caso ele 
esteja logado. Para não ficarmos com código sem explicação, vamos apensar 
dar uma olhada na classe Securit yDAO. 


package br.com.casadocodigo.loja.security; 
//imports 
public class SecurityDAO { 


@PersistenceContext 
private EntityManager em; 


public SystemUser loadUserByUsername(String username) 

throws UsernameNotFoundException { 

String jpql = "select u from SystemUser u 
where u.e-mail = :login"; 

SystemUser user = em.createQuery(jpql, SystemUser.class) 

.setParameter("login", username) 
.getSingleResult(); 
return user; 


Agora, na nossa pagina, basta que usemos 0 objeto exposto pelo CDI na 
expression language. 


<div> 
Seja bem vindo, #{currentUser.get() .e-mail} 
</div> 


Lembre-se de que o padrão é expor o objeto associado a uma chave com 
o mesmo nome da classe, mas com a primeira letra minúscula. 
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Um ponto que pode ter chamado a atenção do leitor mais curioso é o fato 
de a classe CurrentUser não usar o escopo de sessão, já que ela guarda 
referência para o usuário que acabou de logar. O motivo é simples: já que as 
informações do usuário atual são mantidas no request, optamos por deixar a 
nossa classe no mesmo escopo. 

A parte potencialmente ruim é que vamos fazer a query de busca de usuá- 
rio o tempo todo. Entretanto, isso só será um problema se a sua aplicação real- 
mente começar a apresentar problemas de performance. Caso o leitor prefira 
usar o escopo de sessão, fique à vontade para alterar a configuração da classe. 

O código ficaria parecido com: 


@Named 
@SessionScoped 
public class CurrentUser implements Serializable{ 


O único detalhe em que você precisa prestar atenção é com o objeto car- 





regado pelo EntityManager. Uma vez que ele for fechado, o objeto entra 
no estado detached, e qualquer tentativa de lazy load vai gerar uma excep- 
tion. Para essa situação em específico, o melhor cenário é usar uma query 
planejada, já trazendo todas as informações necessárias. 





O uso do EntityManager extended é desencorajado, porque o ob- 
jeto vai ficar no escopo de sessão, e a conexão com o banco seria mantida por 
um tempo maior do que nós gostaríamos. 

Para este autor, manter o objeto no escopo de request é o mais simples e 
mais precavido. Por exemplo, caso o usuário logado atualize alguma informa- 
ção, esta já será refletida no próximo request, uma vez que estamos fazendo 
o carregamento por requisição. 

Apenas para relembrar: quase nunca precisamos começar a pensar na so- 
lução já considerando um requisito de performance. Tente ir pelo caminho 
mais simples e analise os resultados. 


Menu de administração na home da Loja 


Agora que temos uma área de administração protegida, podemos facilitar 
o acesso a ela. Nesse momento, todas as vezes em que o usuário quer acessar 
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o cadastro de livros, ele tem de digitar o endereço no navegador. Para facili- 
tar, vamos adicionar mais uma opção no menu da página inicial da Casa do 
Código. Lembre-se de que o arquivo éo site/index.xhtml. 


<nav id="main-nav"> 


<ul class="clearfix"> 
<li><a href="#{request.contextPath}/livros/list.xhtml" 
rel="nofollow">Administrag&o</a></1i> 


<li><a href="/cart" rel="nofollow"> 
Seu carrinho 
</a></1i> 


<li><a href="/pages/sobre-a-casa-do-codigo" 
rel="nofollow"> Sobre nós 
</a></1i> 


<li><a href="/pages/perguntas-frequentes" 
rel="nofollow"> Perguntas Frequentes 
</a></1i> 


</ul> 
</nav> 


O problema é que agora qualquer usuário pode ver esse menu, mas ele 
só deve ser exibido para os administradores. Podemos mudar um pouco o 
código para fazer essa verificação. 


<html xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core"> 


<nav id="main-nav"> 
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<ul 


class="clearfix"> 
<c:if test="#{currentUser.hasRole(? ADMIN?) }"> 
<li><a href="#{request.contextPath}/ 
livros/list.xhtml" 
rel=''nofollow">Administração</a></li> 
</csif> 


<li><a href="/cart" rel="nofollow"> 
Seu carrinho 
</a></1i> 


<li><a href="/pages/sobre-a-casa-do-codigo" 
rel="nofollow"> Sobre nós 
</a></1i> 


<li><a href="/pages/perguntas-frequentes" 
rel="nofollow"> Perguntas Frequentes 
</a></1i> 


</ul> 


</nav> 


</html> 


Adicionamos mais um método na classe CurrentUser, 0 hasRole. 


package br.com.casadocodigo.loja.security; 


//imports 


@Model 


public class CurrentUser { 


@Inject 
private 
@Inject 
private 
private 


HttpServletRequest request; 


SecurityDAO securityDAO; 
SystemUser systemUser; 


265 


12.4. Exibindo o usuário logado e escondendo trechos da página Casa do Código 





public SystemUser get 01 
return this.systemUser; 


public boolean hasRole(String name) 1 
return request. isUserInRole (name); 


@PostConstruct 
private void loadSystemUser() + 
Principal principal = request.getUserPrincipal(); 
if (principal != null) { 
this.systemUser = securityDAO 
. loadUserByUsername (principal .getName()); 


A implementação é mais fácil do que a gente poderia pensar. Como a API 
de Servlets é integrada com o JAAS, o próprio request já fornece o método 
isUserInRole para verificar se o usuário que se logou possui determinado 
perfil. Lembre-se de que quando damos início ao processo de login, o módulo 
de segurança configurado no WildFly será usado e os perfis do usuário serão 
carregados. Pronto, dessa forma, garantimos que a opção do menu só aparece 
para os usuários que estão logados como administradores. 

Apenas para não passar em branco, foi utilizada a tag if da JSTL para 
verificarmos se o usuário possui o perfil ou não. Como só trabalhamos com 
elementos HTML padrão, não existe nenhuma restrição quanto ao uso dessa 
tag. 

Para não perdermos o foco do capítulo, existe um texto muito bom, um 
pouco antigo, que detalha bem a mistura de tags da JSTL com componentes 
do JSF. Acesse o link http://bit.ly/jstl-jsf e entenda ainda mais sobre questões 
do ciclo de vida. 


266 


Casa do Código Capítulo 12. Protegendo a aplicação 





12.5 CONCLUSÃO 


Neste capítulo, estudamos bastante sobre o JAAS. Apesar de ser uma especi- 
ficação antiga e pouco atualizada, conseguiu atender nossas necessidades da 
nossa aplicação. Fique apenas atento a todas as configurações que fizemos no 
WildFly foram específicas dele, e não podem ser reaproveitadas quando você 
for utilizar outro servidor de aplicação. 

Esse é justamente um dos pontos que vão ser atacados na próxima versão 
do Java EE. A API de segurança vai ser modernizada para que fique mais fácil 
de ser configurada. Você pode acompanhar o andamento em https://jcp.org/ 
en/jsr/detail?id=375. 

Um ultimo ponto que pode, no primeiro momento, causar um pouco de 
desconfiança é o fato de os endereços protegidos serem especificados direta- 
mente no web.xml. Esse, na verdade, é o cenário ideal. Tentar manter suas 
regras simples; é o melhor que você pode fazer. Por exemplo, se as URLs es- 
tivessem cadastradas no banco, como você teria certeza de que os endereços 
necessários realmente estão protegidos? 

Por mais que pareça tentador deixar tudo dinâmico, tente começar pelo 
simples. Caso realmente precise que as associações entre perfis e URLs sejam 
dinâmicas, você vai ter de partir para uma solução mais manual, já que o JAAS 
não possui essa funcionalidade pronta para uso. 

Não pare agora, no próximo capítulo vamos tentar modularizar nosso 


layout, diminuindo as partes que se repetem! 
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CAPITULO 13 


Organização do layout em 
templates 


Já implementamos algumas das funcionalidades que existem dentro do sis- 
tema real do site da Casa do Código. Entretanto, uma parte com que não nos 
preocupamos até agora é em relação à organização do layout da aplicação. E 
esse é um ponto bem relevante, já que o layout também sofre alterações du- 
rante o tempo de vida da aplicação, levando-nos, várias vezes, a problemas de 
manutenção justamente por não dar a devida importância a essa parte. 

Por exemplo, atualmente, entre as páginas que já implementamos, temos 
a de exibição dos detalhes de um livro, a que exibe os produtos do carrinho e a 
que lista os livros disponíveis na loja. Olhando com atenção para elas, vamos 
perceber que ambas possuem o mesmo header e footer. 


<head> 
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</head> 

<header id="layout-header"> 

</header> 

<nav class="categories-nav"> 

</nav> 

<!-- resto da pagina--> 

<footer id="layout-footer"> 

</footer> 

Aqui temos o problema clássico de repetição. Caso alguma mudança seja 

necessária nesses trechos, vamos ter de sair caçando em todas as páginas. 


Uma maneira comum de resolver essa situação é utilizando o sistema de in- 
cludes, que já é suportado em aplicações JSF, por meio do Facelets. 


<html xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core"> 


<head> 
<meta charset="utf-8"/> 
<meta http-equiv="X-UA-Compatible" content="IE=edge, 
chrome=1"/> 
<meta name="Viewport" content="width=device-width, 
initial-scale=1, maximum-scale=1"/> 


</head> 
<body class="index"> 


<ui: include src="header .xhtml''/> 


...resto da pagina 
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<ui: include src="footer.xhtml''/> 
</body> 
</html> 


Até isolamos o header eo footer, só que sobrou esse início de de- 
claração do HTML. Aí você pode pensar: não tem problema, é só criar mais 
uma include e isso também vai estar isolado. Só que aí é que entra um outro 
problema: para uma pessoa nova montar uma página, seguindo o padrão do 
sistema, ela tem de saber de todas essas includes e ainda tem de saber a ordem! 
A tendência é só piorar. 


13.1 TEMPLATES 


Para amenizar esse problema, a especificação do JSF já pensou em uma solu- 
ção. A ideia é que possamos criar um modelo de página que possa ser usado 
por todas as outras telas. Esse é mais um mecanismo suportado pelo Facelets. 

Vamos dar uma olhada em como vai ficar a página site /index. xhtml, 
utilizando essa espécie de molde. 


<html xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core"> 


<ui:composition template="/site/_template.xhtml"> 
<ui:define name="extraCss"> 
<link href= 
"#{request .contextPath}/resources/css 
/book-collection.css" rel="stylesheet" 
type="text/css" media="all" /> 
</ui:define> 


<ui:define name="body"> 


<section id="index-section" 
class="container middle"> 
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</section> 
</ui:define> 
</ui: composition> 


</html> 


Atag composition é usada para indicar que queremos usar um modelo 
padrão de página, também conhecido como template. Perceba que até usamos 
um atributo também chamado template, e passamos o caminho do arquivo 
que servirá de modelo para as páginas da nossa loja. 

Antes de analisar o arquivo que vai servir de base, vamos continuar ana- 
lisando as outras tags que usamos. A tag define deve ser utilizada para 
informar que a página atual passará alguns trechos de código que devem ser 
usados pela master page, de modo a completar a estrutura da página. 


e extraCss - usamos para passar o HTML necessário com os estilos 
específicos da página; 


* body - usamos para passar o HTML específico da página atual. 


Podemos ter quantas tags define forem necessárias, tudo vai depender 
de como o template foi organizado. Vamos agora dar uma olhada no arquivo 
site/ template.xhtml para ver como podemos montar a estrutura da 
página. 


<html xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core" 
xmlns:h="http://java.sun.com/jsf/htm1" 
xmlns:f="http://java.sun.com/jsf/core"> 


<head> 
<ui:include src="head.xhtml1"/> 


<ui:insert name="extraCss"/> 
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</head> 
<body class="index"> 


<ui: include src="header.xhtml1"/> 
<ui:insert name="body"/> 


<ui: include src="footer.xhtml''/> 
</body> 
</html> 


Perceba que é uma página normal, a única tag nova que usamos foi a 
insert. Ela serve justamente para demarcamos os pontos da página que 
serão preenchidos pela página que for usar esse template, como foi o caso da 
site/index.xhtml. 

O valor do atributo name da tag insert tem de ser exatamente o mesmo 
do atributo name da tag define, para que o Facelets consiga fazer a associ- 
ação e montar a página final. 

Um último detalhe, não menos importante: as tags novas que usamos 
estão disponíveis no namespace http://xmins.jcp.org/jsf/facelets, que foi refe- 


renciado pelo prefixo ui na nossa página. 


<html xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:ui="http://xmlns. jcp.org/jsf/facelets" 
ie 


</html> 


Detalhe especial sobre a tag composition 


Um ponto que pode ter ficado na sua cabeça foi o uso da tag html para 
importar as taglibs que usamos dentro das páginas _template.xhtml e 
site/index.xhtml. Analisando, fica parecendo que a tag html vai ser 
renderizada duas vezes: uma pelo template e outra pela página específica. 

É justamente aí que entra o uso da tag composition. Tudo o que está 
fora dela é ignorado no momento da renderização da página e, por conta 
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disso, nao corremos 0 risco de ter as tags duplicadas no resultado final. 


<html xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core"> 


<!-- Tudo que tem daqui pra cima é ignorado--> 
<ui:composition template="/site/_template.xhtml"> 


</ui: composition> 
<!-- Tudo que tem daqui pra baixo é ignorado--> 
</html> 


Passando parâmetros para o template 


Um outro detalhe que talvez tenha passado desapercebido foi o uso do 
atributo class, na tag body do template principal. 


<html xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core" 
xmlns:h="http://java.sun.com/jsf/htm1" 
xmlns:f="http://java.sun.com/jsf/core"> 


<head> 
<ui:include src="head.xhtml1"/> 


<ui:insert name="extraCss"/> 


</head> 
<body class="index"> 


<ui:include src="header.xhtml"/> 
<ui:insert name="body"/> 


<ui: include src="footer.xhtml"/> 
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</body> 
</html> 


Ela sempre está assumindo que a página que utilizará o template será a 
index.xhtml. O problema é que cada pagina tem a sua classe específica, 
por exemplo, a tela com os itens do carrinho usa a classe cart. Esse é um 
caso em que não podemos usar a tag insert, já que não queremos definir 
um trecho de HTML, mas sim apenas um parâmetro. 

Para este tipo de situação, vamos usar a tag param. Vamos dar uma 
olhada como ficaria a tela do carrinho de compras: 


<html xmins:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmlns: pt="http://xmlns.jcp.org/jsf/passthrough" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns: jsf="http://xmlns.jcp.org/jsf"> 


<ui:composition template="/site/_template.xhtml"> 
<ui:param name="bodyClass" value="cart"/> 
<ui:define name="body"> 


</ui:define> 
</ui: composition> 
</html> 


Perceba que usamos a tag param para definir um parâmetro de nome 
bodyClass. Agora, no template, basta que acessemos a variável que foi de- 
finida, via expression language. 


<html xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core" 
xmlns:h="http://java.sun.com/jsf/htm1" 
xmlns:f="http://java.sun.com/jsf/core"> 


<head> 
<ui:include src="head.xhtml1"/> 
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<ui: insert name="extraCss"/> 


</head> 
<body class="#{bodyClass}"> 


<ui: include src="header.xhtml"/> 
<ui:insert name="body"/> 


<ui: include src="footer.xhtml"/> 
</body> 
</html> 


Pronto! Agora temos um layout bem organizado e pronto para ser evo- 
luído. Podemos alterar a ordem das informações, e não será necessário alterar 
nenhum arquivo que use o template. Além disso, os trechos definidos pela tag 
insert não são de passagem obrigatória, o que fornece ainda mais flexibili- 


dade. 


13.2 CONCLUSÃO 


Este capítulo foi bem rápido, apenas organizamos um pouco mais nosso 
layout. Não usamos nenhuma especificação nova em si, mas mesmo assim 
foi importante, já que as telas compõem uma parte fundamental de qualquer 
aplicação. 

Não pare agora, já comece o próximo capítulo para que possamos fazer 
com que nossa aplicação suporte vários idiomas. 

Apenas como lembrete: todos os arquivos de layout podem ser 
encontrados no repositório do livro, em https://github.com/asouza/ 
casadocodigojavaee. 

Você também pode acessar o commit específico da organização do layout. 
É só acessar o link http://bit.ly/commit-facelets. 
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Internacionalização 


Até este momento, todos os textos da aplicação estão escritos diretamente 
nas páginas. Por exemplo, vamos analisar o menu de navegação da include 
que contém o header do projeto. 


<div id="header-content"> 
<nav id="main-nav"> 


<ul class="clearfix"> 
<c:if test="#{currentUser.hasRole(? ADMIN?) }"> 
<li><a href="#{request.contextPath}/livros 
/list.xhtml" rel="nofollow"> Administração 
</a></1i> 
</ferit> 


<li><a href="/cart" rel="nofollow"> 
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Seu carrinho 
</a></1i> 


<li><a href="/pages/sobre-a-casa-do-codigo" 
rel="nofollow"> 
Sobre nós 
</a></1i> 


<li><a href="/pages/perguntas-frequentes" 
rel="nofollow"> 
Perguntas Frequentes 
</a></1i> 
</ul> 
</nav> 
</div> 


Todos os textos da aplicação estão escritos diretamente na página e, em 
geral, talvez isso não seja um problema. Entretanto, o site da Casa do Código 
já tem a sua versão internacional, a Code Crushing. Eles têm o mesmo layout 
e só mudam em uma coisa: todos os textos são escritos em inglês. 


14.1 ISOLANDO OS TEXTOS EM ARQUIVOS DE MENSA- 
GENS 


Caso continuemos com a estratégia de escrever os textos diretamente nas pá- 
ginas, teríamos de duplicar cada uma delas. Para conseguirmos internacio- 
nalizar nossa aplicação, vamos ter de isolar os textos em um novo arquivo de 


propriedades, dessa vez o messages.properties. 


menuPrincipal admin = Administração 

menuPrincipal seularrinho = Carrinho 

menuPrincipal sobre = Sobre 

menuPrincipal perguntasFrequentes = Perguntas frequentes 


Usamos um novo arquivo, já que o outro que criamos,o jsf messages, 
foi configurado para ter as mensagens específicas do JSF, e não da aplicação 
em si. Esse novo arquivo também deve ficar no classpath do projeto, por 
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isso que ele deve ser criado em src/main/resources. A nomenclatura 
em um arquivo properties sempre é fonte de discussão. 

Aqui estamos seguindo o seguinte: dividimos os grupos com o _ e usa- 
mos o camelCase para os nomes dos itens em si. Agora que já isolamos os 
textos no arquivo messages, podemos usar as chaves nas nossas páginas. 


<div id="header-content"> 
<nav id="main-nav"> 


<ul class="clearfix"> 
<c:if test="#{currentUser.hasRole(? ADMIN?) }"> 
<li><a href="#{request.contextPath}/livros 
/list.xhtml" rel="nofollow"> 
menuPrincipal_admin 
</a></1i> 
CCR if> 


<li><a href="/cart" rel="nofollow"> 
menuPrincipal_seuCarrinho 
</a></1i> 


<li><a href="/pages/sobre-a-casa-do-codigo" 
rel="nofollow"> 
menuPrincipal_sobre 

</a></1i> 


<li><a href="/pages/perguntas-frequentes" 
rel="nofollow"> 
menuPrincipal_perguntasFrequentes 
</a></1i> 
</ul> 
</nav> 
</div> 


O problema é que precisamos acessar os valores associadas a essas cha- 
ves. Para isso, precisamos ensinar o JSF a carregar o arquivo e deixar as 
chaves disponíveis para serem usadas nas páginas. Vamos alterar o arquivo 





faces-config.xml, para adicionar a tag resource-bundl 
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<application> 
<message-bundle>jsf messages</message-bundle> 
<resource-bundle> 
<base-name>messages</base-name> 
<var>msg</var> 
</resource-bundle> 
</application> 


A tag  base-name indica a localização do arquivo, dentro 
do classpath do nosso projeto. Como deixamos o arquivo em 
src/main/resources, que fica na raiz do classpath, só precisa- 
mos passar o nome. A tag var é utilizada para informar o nome da variável 
que ficará disponível para acessarmos nas páginas. 


<div id="header-content"> 
<nav id="main-nav"> 


<ul class="clearfix"> 
<c:if test="#{currentUser.hasRole(’ ADMIN?) }"> 
<li><a href= 
"#{request .contextPath}/livros/list.xhtml" 
rel="nofollow">#{msg.menuPrincipal_admin} 
</a></1i> 
</ciif> 


<li><a href="/cart" rel="nofollow"> 
#{msg.menuPrincipal_seuCarrinho} 
</a></1i> 


<li><a href="/pages/sobre-a-casa-do-codigo" 
rel="nofollow"> 
#{msg.menuPrincipal_sobre} </a></1i> 


<li><a href="/pages/perguntas-frequentes" 
rel="nofollow"> 
#{msg.menuPrincipal_perguntasFrequentes} 
</a></1i> 
</ul> 
</nav> 
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</div> 


A variável msg guarda a referência para um mapa carregado com as infor- 
mações do arquivo de propriedades. O acesso às chaves por meio da sintaxe 
#{msg.chave} é apenas um syntax sugar para * (msg [chave] }. 


14.2 ACCEPT-LANGUAGE HEADER 


Até agora, temos apenas o arquivo messages.properties com os tex- 
tos em português. Só que precisamos suportar as mensagens também em 
inglês. Para fazer isso, precisamos criar o arquivo com a extensão da lo- 
calização que queremos suportar. Por exemplo, podemos criar o arquivo 


messages en.properties. 


menuPrincipal admin = Admin 

menuPrincipal seularrinho = Shopping Cart 
menuPrincipal sobre = About 

menuPrincipal perguntasFrequentes = Frequent questions 


Podemos também criar o arquivo com a extensão _pt.properties, 
para suportar o português padrão. Para que o JSF saiba quais locales 
ele deve aceitar, precisamos adicionar mais uma configuração no 


faces-config 


<application> 
<message-bundle>jsf messages</message-bundle> 
<resource-bundle> 
<base-name>messages</base-name> 
<var>msg</var> 
</resource-bundle> 
<locale-config> 
<default-locale>pt</default-locale> 
<supported-locale>en</supported-locale> 
</locale-config> 
</application> 


Definimos qual a língua padrão e ainda adicionamos as outras que são su- 
portadas. A pergunta que fica é: como o JSF descobre qual idioma o navegador 
prefere? 
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Fig. 14.1: Header com a opção de língua 


A resposta está no cabeçalho da requisição HTTP. Perceba que há uma 
chave chamada Accept-Language, e é nela que vêm as línguas prediletas do 
seu usuário. No caso do navegador do autor deste livro, está como português. 
Tanto que a primeira opção é o pt. Porém, caso nosso sistema não suporte 
esse idioma, ele fala que prefere o en-US. 

Carregar o arquivo de mensagens em função da língua do navegador é a 
maneira padrão de o JSF lidar com a internacionalização. 


14.3 PASSANDO PARÂMETROS NAS MENSAGENS 


Outra situação muito comum no momento de exibir as mensagens interna- 
cionalizadas é a necessidade de que a mensagem seja construída dinamica- 
mente. Por exemplo, na página de listagem de livros, queremos dar boas- 
vindas ao usuário que acabou de logar no sistema. 


Seja bem vindo, #{currentUser.get() .email} 


Vamos deixar inclusive essa mensagem internacionalizada. Para isso, va- 


mos acrescentar a entrada no arquivo de mensagens. 


usuarios.bemVindo = Olá {0} 


Para representar os parâmetros, usamos os índices. Esta técnica já vem 
suportada por padrão no suporte à internacionalização presente no próprio 
Java. Agora, para usar na página, podemos usar a tag do JSF. 


<h:outputFormat value="#{msg.usuarios_bemVindo}"> 
<f:param value="#{currentUser.get().email}" /> 
</h: outputFormat> 
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A tag outputFormat deve ser utilizada sempre que você quiser escrever 
um texto parametrizado. Passamos o texto com os parâmetros para o atributo 
value, e fazemos uso da tag param para ir definindo os valores de cada 
índice. Caso você tenha mais de um índice, passe o número equivalente de 


tags param. 


14.4 DEIXE QUE O USUÁRIO DEFINA A LÍNGUA 


Respeitar o idioma sugerido pelo navegador é uma ótima forma de tentarmos 
acertar a língua preferida pelo usuário. O problema dessa abordagem é se o 
idioma configurado não for realmente o seu preferido. 

Nesse momento, caso você esteja achando que todo mundo pode trocar 
isso facilmente, pense em todas as pessoas que você já conheceu que não ti- 
nham muito conhecimento de computação. Muitos usuários, por exemplo, 
apesar de usarem diariamente um navegador, não sabem como fazer essa 
troca. 

Uma estratégia adotada por alguns sites é a de oferecer links para que o 
próprio usuário possa definir o idioma predileto. 
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Latin America 


Argentina / Spanish 
Bolívia / English 
Bolivia / Spanish 
Brazil / Portuguese 
Chile / Spanish 
Colombia / Spanish 
Costa Rica / English 
Costa Rica / Spanish 
Ecuador / English 
Ecuador / Spanish 

El Salvador / English 
El Salvador / Spanish 
Guatemala / English 
Guatemala / Spanish 
Honduras / English 
Honduras / Spanish 


EHHE P liil FaH HH 


4 


HH 


Jamaica / English 
Jamaica / Spanish 
Nicaragua / English 
Nicaragua / Spanish 
Peru / Spanish 
Panama / English 
Panama / Spanish 


Puerto Rico / English 

Puerto Rico / Spanish 
Republica Dominica / English 
Republica Dominica / Spanish 
Trinidad & Tobago / English 
Trinidad & Tobago / Spanish 
Venezuela / Spanish 


Fig. 14.2: Bandeiras dos países 


Vamos adotar a mesma abordagem para a Casa do Código. Inicialmente, 


vamos adicionar os links para que o usuário possa escolher. Faremos isso no 


arquivo header. xhtml:. 


<nav id="main-nav"> 


<ul class="clearfix"> 


.changeLocale(’pt’)}" 


eli 
<h: form> 
<h: commandLink action="#{i18nBean 
value="#{msg.lingua_pt}" /> 
</h:form> 
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</li> 
<li> 
<h:form> 
<h:commandLink action="#{i18nBean 
.changeLocale(’en’) }" 
value="#{msg.lingua_en}" /> 
</h:form> 
</li> 
</nav> 


Já até definimos os links com as actions para um bean nosso, que vai ser 


o responsável por trocar o idioma da aplicação. 


package br.com.casadocodigo.loja.managedbeans.admin; 
//imports 


@Model 
public class I18nBean implements Serializable { 


@Inject 
private FacesContext context; 


public String changeLocale(String language) { 
context.getApplication() 
.setDefaultLocale(new Locale(language) ) ; 
return "/site/index.xhtml?faces-redirect=true"; 


O código anterior até funciona, mas o problema é que trocamos o 
locale para a aplicação toda. Na verdade, o que queremos é trocar o idi- 
oma apenas para o uso de um usuário. 

A melhor maneira de fazer isso é mantendo o nosso bean no escopo de 
session em vez do escopo de request, para que o idioma setado seja mantido 
enquanto o usuário estiver navegando pela aplicação. 
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@Named 
@SessionScoped 
public class 118nBean implements Serializable { 


private Locale locale; 
@Inject 
private FacesContext context; 


public String changeLocale(String language) { 
this.locale = new Locale(language) ; 
return "/site/index.xhtml?faces-redirect=true"; 


public Locale getLocale() { 
return locale; 


O detalhe estranho desse código é que em momento algum invocamos 
um método da API do JSE Esse é justamente nosso trabalho, é necessário 
fazer com o que o locale escolhido pelo usuário seja passado para o JSF 
em toda requisição! É isso mesmo, o JSF não provê uma maneira padrão de 
manter o idioma escolhido entre várias requisições. 

Para fazer isso, podemos usar a tag view. Como todas as telas da loja 
são baseadas no template definido no arquivo _template. xhtml, podemos 
alterá-lo para que o locale seja configurado para cada página. 


<html xmins="http://www.w3.0rg/1999/xhtml" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core" 
xmlns:h="http://java.sun.com/jsf/htm1" 
xmlns:f="http://java.sun.com/jsf/core"> 


<f:view locale="#{i1l8nBean.locale}"/> 


As tags do namespace http://java.sun.com/jsf/core, cujo o prefixo padrão é 
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f, são geralmente usadas quando queremos fazer configurações que não têm 
a ver exatamente com a página, mas sim com alguma configuração do JSF. 
O atributo locale recebe como argumento um objeto do tipo Locale, 
justamente o que é retornado pelo método getLocale da nossa classe 
118nBean. 

Dessa forma, conseguimos sempre definir o locale para cada página 
acessada, e ainda permitimos que o usuário da aplicação o altere sempre que 
quiser. 

Uma última pergunta que pode estar na sua cabeça é: e quando o usuá- 
rio acessar a loja pela primeira vez, qual o locale que será usado? Para 
resolver isso, podemos recuperar o idioma padrão, que foi configurado no 
faces-config, e guardar no nosso atributo. 


@Named 
@SessionScoped 
public class 118nBean implements Serializable { 


private Locale locale; 
@Inject 
private FacesContext context; 


@PostConstruct 
private void loadLDefaultLocale() { 
this.locale = 
context .getApplication() .getDefaultLocale() ; 


public String changeLocale(String language) { 
this.locale = new Locale(language) ; 
return "/site/index.xhtml?faces-redirect=true"; 


public Locale getLocale() { 
return locale; 
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Agora, toda vez que o usuário acessar a aplicação pela primeira vez, ele 
verá a página em português. Caso ele prefira outro idioma, basta clicar no 
link! 


14.5 CONCLUSÃO 


Este capítulo também foi tranquilo. Internacionalização é um tema muito co- 
mum entre todas as aplicações, lembre-se apenas de não ser radical. Caso você 
não tenha planos de fazer outras versões, não se preocupe com esse detalhe. 
Só o use se realmente for necessário, afinal de contas, você está deixando de 
dar manutenção só em um lugar para dar em dois! Antes era apenas a página, 
agora é a página e o arquivo de mensagens. 

No próximo capítulo, discutiremos sobre uma técnica que está em evi- 
dência, a utilização de WebSockets. Através dela, vamos disparar notificações 
para o nosso navegador de uma maneira muito simples! Por conta disso, não 
pare de ler agora, e já devore o próximo capítulo. 
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Enviando e recebendo 
informações via WebSocket 


Uma funcionalidade desejada pela loja é a de poder avisar os clientes sobre 
promoções relâmpago. A ideia é que o administrador possa decidir que algum 
livro fique em promoção em determinado instante, e que todos os usuários 
que estejam em alguma página naquele momento sejam notificados. 


15.1 (COMO NOTIFICAR OS USUÁRIOS? 


A pergunta que fica na nossa cabeça é: como vamos enviar alguma coisa para 
a página que está sendo acessada pelo usuário, naquele instante? Uma das so- 
luções mais antigas era implementar um JavaScript que fica, de tempos em 
tempos, consultando uma URL do servidor para saber se algo novo aconte- 


15.2. API de WebSockets e o navegador Casa do Cédigo 





ceu. 


//exemplo usando um pouco de jquery 
setInterval (function(){ 
$.ajax({ 
url: "/sales", 
success: function(data) { 
//Atualiza o valor de cada ação na tabela 
+, dataType: "json"}); 
+, 30000); 


Poderíamos criar um resource do JAX-RS que responderia para essa re- 
quisição. O grande problema dessa abordagem é que o cliente fica o tempo 
inteiro disparando requisição contra o servidor, mas na maioria das vezes não 
tem nada de novo acontecendo! Basicamente, estamos metralhando o servi- 
dor com várias requisições inúteis. 


15.2 API DE WEBSOCKETS E O NAVEGADOR 


Na verdade, o que precisamos é que quando alguma promoção seja cadas- 
trada, o servidor notifique o cliente com a novidade. Para contornar o pro- 
blema de ficar fazendo requisição o tempo inteiro, ainda antigamente, os ser- 
vidores começaram a suportar que certas conexões abertas pelo cliente não 
fossem fechadas, técnica conhecida como Comet. 

Essa foi uma técnica criada justamente para os servidores começarem a 
suportar o chamado Long Polling e, dessa forma, pudessem enviar informa- 
ções para o cliente sem a necessidade de uma nova requisição. 

Pois bem, na última versão do HTMLs, esse tipo de técnica virou uma 
especificação chamada WebSocket. Só que eles foram além de só especificar o 
que já tinha pronto, e adicionaram novos detalhes: 


e Além de o servidor poder notificar o cliente, o cliente também pode 
enviar informações para o servidor; 


e A comunicação é feita baseada em um novo protocolo, chamado justa- 
mente de WebSocket; 
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* API padrão para ser usada dentro do navegador em vez de ficar simu- 


lando requisição AJAX. 


Usando a API de WebSockets no navegador 


Vamos começar a implementar nossa nova funcionalidade. A primeira 


coisa que precisamos é abrir o WebSocket na página para podermos man- 


dar e receber informações pela mesma conexão. Como queremos que, inde- 


pendente da página, o usuário seja notificado, vamos deixar esse código no 


_template.xhtml. 


<html xmlns="http://www.w3.org/1999/xhtm1" 
xmlns:ui="http://xmlns.jcp.org/jsf/facelets" 
xmlns:o="http://omnifaces.org/ui" 
xmlns:c="http://java.sun.com/jsp/jstl/core" 
xmlns:h="http://java.sun.com/jsf/html1" 
xmlns:f="http://java.sun.com/jsf/core"> 


<f:view locale="#{i18nBean.locale}"/> 
<head> 
<ui:include src="head.xhtml1"/> 


<ui:insert name="extraCss"/> 


</head> 
<body class="#{bodyClass}"> 


<ui:include src="header.xhtml1"/> 
<ui:insert name="body"/> 


<ui: include src="footer.xhtm1"/> 

<script> 
var salesChannel = new WebSocket ( 
"ws://localhost : 8080/#{request .contextPath} 
/channel/sales") ; 

</script> 

</body> 
</html> 
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Criamos um novo objeto do tipo WebSocket, passando justamente o en- 
dereço que precisamos manter o link aberto com o cliente. Perceba, inclusive, 
que o protocolo usado não é o HTTP, e sim o WS, de WebSocket. 


Agora que a conexão está aberta, precisamos receber as novas mensagens, 
que serão enviadas a partir do servidor. 


salesChannel .onmessage = function (message) { 
var newSale = JSON.parse (message .data); 
if (confirm("Quer participar da seguinte promocao: " 
tnewSale.titlet"?")){ 
document.location.href = 
"#{request .contextPath}/site/ 
detalhe.xhtml?id="+newSale.bookId; 


3; 


A propriedade onMessage aceita um função que vai ser invocada sem- 
pre que o servidor enviar uma nova mensagem para o cliente. Perceba que 
a nossa função simplesmente leva o usuário para a tela de detalhes do livro 
com o id igual ao que foi recebido como argumento. A API de WebSockets 
é muito direta, a abstração criada pela especificação realmente deixou tudo 
muito simples. 

Um outro detalhe que vale analisar com mais carinho é o formato da men- 
sagem. Ela sempre chega como um JSON e, por meio da propriedade data, 
conseguimos acessar o texto que foi enviado pelo servidor. 

Também é interessante notar o console do navegador. Quando acessamos 
uma página que abre um WebSocket, a requisição fica aberta com o status 101, 
que representa a conexão em andamento. 
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Fig. 15.1: Conexão aberta via WebSocket 


Caso você use o serviço do WhatsApp Web, abra o console da página e 
perceba que ele usa um WebSocket para ficar enviando e recebendo novas 


mensagens. 


15.3 ENVIANDO MENSAGENS A PARTIR DO SERVIDOR 


Como foi comentado, precisamos de uma nova tela na aplicação para permitir 
que o o administrador da loja consiga lançar novas promoções no sistema. 
Podemos criar esse formulário em promocoes/form.xhtml. 


<html xmlns:h="http://java.sun.com/jsf/html" 
xmins:f="http://xmlns.jcp.org/jsf/core" 
xmins="http://www.w3.0rg/1999/xhtml" 
xmins:pt="http://xmins.jcp.org/jsf/passthrough'!> 


<h: body> 
<h:messages /> 
<h:form> 
<div> 
<h: outputLabel>Titulo</h: outputLabel> 
<h: inputText 
value="#{adminSalesBean.sale.title}" 
label="titulo"/> 
</div> 
<div> 
<h:outputLabel for="livro"> 
Livro 


</h:outputLabel> 
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<h:selectOneMenu 
value="#{adminSalesBean.sale.book.id}" 
id="1ivro"> 
<f:selectItems 
value="#{adminListBooksBean.books}" 
var="book" 
itemLabel="#{book.title}" 
itemValue="#{book.id}"/> 
</h:selectOneMenu> 
</div> 


<h: commandButton value="Gravar" 
action="#{adminSalesBean.save}"/> 
</h: form> 
</h:body> 
</html> 


Em relação ao JSF, não temos nada de novo. O detalhe interessante está 
apenas no uso da tag select Items. Precisamos da lista de livros cadastra- 
dos. Em vez de fazer uma nova lógica para isso, aproveitamos o bean que já 
existe. 

Lembre-se sempre de que não existe nenhuma regra que impõe a neces- 
sidade de criar um bean para cada tela. Divida suas classes de forma a reapro- 
veitar as responsabilidades, sem perder a coesão. 

Além de reaproveitar a listagem de livros, precisamos de um novo bean 
que será responsável por tratar a solicitação de uma nova promoção. 


package br.com.casadocodigo. loja. managedbeans.admin; 
//imports 


@Model 
public class AdminSalesBean { 


private Sale sale = new Sale(); 


@PostConstruct 
private void configure() { 
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this.sale.setBook(new Book()); 


public String save() { 
//precisamos notificar os usuários sobre a promoção 
return "/admin/promocoes/form. xhtml?faces-redirect=true" ; 


public Sale getSale() { 
return sale; 


public void setSale(Sale sale) { 
this.sale = sale; 


De novo, apenas códigos que já estudamos! Para que nosso código com- 
pile, também é necessário que seja criada a classe Sale, a abstração de uma 
nova promoção no sistema. 


package br.com.casadocodigo.loja.models; 
//imports 
public class Sale { 


private String title; 
private Book book; 


public String getTitle() { 
return title; 


public void setTitle(String title) 1 
this.title = title; 
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public Book getBook() { 
return book; 


public void setBook(Book book) { 
this.book = book; 


Agora, só falta resolvermos justamente a parte de enviar a mensagem via 
WebSocket. Um último detalhe: não se esqueça de adicionar o novo endereço 
na configuração do JAAS no seu web.xml. Não queremos que os usuários 
que não são administradores lancem promoções no sistema. 


WebSockets no Java EE 


Entendendo a nova tendência das aplicações web, a especificação Java EE 
não perdeu tempo e adicionou o suporte à comunicação via WebSocket. O 
mais legal de tudo isso é que realmente ficou muito simples suportar esse mo- 
delo dentro da nossa aplicação. 

A nossa primeira tarefa é a de aceitar uma nova conexão via WebSocket. 


package br.com.casadocodigo.loja.websockets; 
import javax.websocket.server.ServerEndpoint ; 


@ServerEndpoint ("/channel/sales") 
public class SalesEndpoint { 


É uma configuração bem parecida com a que fazemos quando precisa- 
mos de um Servlet. Só que, em vez de usarmos a annotation @WebServlet, 





usamos a nova annotation @ServerEndpoint. Também somos obrigados a 
passar o endereço em que a conexão via WebSocket será aberta. Perceba que 
a URL é a mesma utilizada dentro da nossa página. 

Agora que a conexão está aberta, é necessário que o nosso bean de cadas- 
tro de promoções seja capaz de mandar uma mensagem para cada cliente que 
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abriu um novo WebSocket nesse endpoint. Para saber que uma nova cone- 
xão foi solicitada, basta que um método seja criado e anotado com @OnOpen. 


import javax.inject.Inject; 
import javax.websocket. On0pen; 
import javax.websocket.Session; 


@ServerEndpoint ("/channel/sales") 
public class SalesEndpoint { 


@Inject 
private ConnectedUsers connectedUser; 


COn0pen 
public void onNewUser (Session session) { 
connectedUser.add(session); 


Podemos dar qualquer nome para o método, o importante é que ele esteja 
anotado com OnOpen. Além disso, podemos receber um parâmetro do tipo 
Session, que representa a conexão estabelecida entre o cliente e o servidor. 
Quando uma nova promoção for lançada, vamos precisar de todos objetos do 
tipo Session para que possamos notificar cada um deles do novo evento. 
Uma primeira solução poderia ser guardar esse conjunto dentro da própria 





classe SalesEndpoint 


@ServerEndpoint ("/channel/sales") 
public class SalesEndpoint { 


private Set<Session> remoteUsers = new HashSet<>(); 
@On0pen 


public void onNewUser(Session session) { 
remoteUsers.add(session) ; 
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O problema é que a especificação diz que, para cada nova conexão, um 





novo objeto da classe anotada com @ServerEndpoint será criado e, por 
conta disso, sempre vamos perder os clientes que já estavam adicionados no 
nosso Set. 

Para resolver essa situação, podemos criar uma outra classe que será res- 
ponsável por manter as referências aos usuários que estão conectados naquele 
momento. 


package br.com.casadocodigo.loja.websockets; 


//outros imports 
import javax.websocket.Session; 


CApplicationScoped 
public class ConnectedUsers { 


private Set<Session> remoteUsers = new HashSet<>(); 
private Logger logger = 
LoggerFactory.getLogger (ConnectedUsers. class); 


public void add(Session remoteUser) { 
this.remoteUsers.add(remoteUser) ; 


O código é basicamente o mesmo que tínhamos escrito, só 
que agora mantemos a lógica dentro de uma classe anotada com 
@ApplicationScoped. Graças ao CDI, podemos injetar um objeto 
deste tipo dentro da nossa classe SalesEndpoint. 





package br.com.casadocodigo.loja.websockets; 


import javax.inject.Inject; 

import javax.websocket. On0pen; 

import javax.websocket.Session; 

import javax.websocket.server.ServerEndpoint ; 
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@ServerEndpoint ("/channel/sales") 
public class SalesEndpoint { 


@Inject 
private ConnectedUsers connectedUsers; 


COn0pen 
public void onNewUser(Session session) { 
connectedUsers.add(session) ; 


Como o escopo da classe ConnectedUsers é de aplicação, conseguimos 
manter uma lista única com todos usuários conectados naquele momento. 
Agora que já temos quase tudo pronto, podemos voltar para o nosso bean, e 
finalmente disparar a mensagem! 


package br.com. casadocodigo. loja.managedbeans.admin; 
//imports 


@Model 
public class AdminSalesBean { 


private Sale sale = new Sale(); 
@Inject 
private ConnectedUsers connectedUsers; 


@PostConstruct 
private void configure() { 
this.sale.setBook(new Book()); 


public String save() { 
connectedUsers.send(sale.toJson()); 
return "/admin/promocoes 
/form. xhtml?faces-redirect=true"; 
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public Sale getSale() { 
return sale; 


public void setSale(Sale sale) { 


this. 


sale = sale; 


Apenas recebemos injetado o objeto do tipo ConnectedUsers, e in- 


vocamos o método send passando um JSON como argumento. O método 


send vai ser o responsável por enviar as mensagens para o cliente, também 


via WebSocket. 


package br.com.casadocodigo.loja.websockets; 


import javax. 
import javax. 
import javax. 
import javax. 


inject.Inject; 

websocket. On0Open; 

websocket .Session; 
websocket.server.ServerEndpoint; 


@ServerEndpoint ("/channel/sales") 


public class 


@Inject 


SalesEndpoint { 


private ConnectedUsers connectedUsers; 


COn0pen 


public void onNewUser (Session session) { 


connectedUsers.add (session); 


public void send(String message) { 


for (Session user : remoteUsers) { 
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} catch (IOException e) { 
logger.error("N&o foi possivel enviar 
mensagem para um cliente, {}",e); 


O método getBasicRemote retorna o objeto capaz de mandar mensa- 
gens para o cliente conectado. Por fim, o método sendText é o responsável 
por enviar uma mensagem no formato texto. 

É tudo tão simples que parece até estranho, mas como já mostramos du- 
rante o livro, o Java EE caminhou para um alto nível de simplicidade. A mai- 
oria das especificações já está baseada em APIs de uso fácil, e as mais antigas, 
como o JAAS, estão sendo atualizadas para virem mais simples no Java EE 8. 

Para não ficarmos com um código sem explicação, vamos apenas olhar o 
método toJson na classe Sale. 


package br.com.casadocodigo.loja.models; 


import javax.json.Json; 
import javax.json.Json0bjectBuilder; 


import br.com.casadocodigo.loja.models.Book; 
public class Sale { 


private String title; 
private Book book; 


//outros métodos 
public String toJson() { 
JsonObjectBuilder sale = Json.createObjectBuilder (); 


sale.add("title", this.title) 
.add("bookId", this.book.getId()); 
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return sale. build() .toString() ; 


Apenas usamos um pouco mais da nova especificação de geração de 
JSON, presente no Java EE 7. 


15.4 OUTROS DETALHES DA ESPECIFICACAO DE WEB- 
SOCKETS 


Nossa funcionalidade já está implementada, vamos apenas tentar deixar 
nosso código um pouco melhor. Por exemplo, caso um usuário feche o nave- 
gador, a sua conexão WebSocket será perdida, mas mesmo assim ainda man- 
temos a referência para ele na classe ConnectedUsers. O melhor é que 
retiremos esse cliente, para não termos objetos inválidos. 


@ServerEndpoint ("/channel/sales") 
public class SalesEndpoint { 


//outros métodos 


COnClose 

public void onClose(Session session,CloseReason closeReason) { 
connectedUsers. remove (session); 
System. out .print1n(closeReason. getCloseCode()); 


Continuando na linha da simplicidade, basta que anotemos o nosso mé- 
todo com @OnClose. Recebemos um objeto do tipo Session que, como já 
vimos, representa a conexão com o cliente. Além disso, ainda podemos rece- 
ber um objeto do CloseReason que, como o próprio nome diz, retorna o 
motivo da quebra da conexão. 

Para fechar, caso sua aplicação necessite receber mensagens do cliente, 
basta que seja criado um método anotado com OnMessage e, assim como 
fizemos para enviar, podemos receber uma String como argumento. 
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15.5 CONCLUSÃO 


O uso de WebSockets já é uma realidade nas aplicações. Muitas das que usa- 
mos (como WhatsApp Web, Slack etc.) usam essa API para poder enviar e 
receber mensagens de um servidor. O exemplo mais comum encontrado pelo 
mundo é a criação de um chat, mas mostramos que a aplicação do conceito 
vale para outras situações também. 

Caso você tenha a necessidade de usar vários WebSockets na sua 
aplicação, nada impede que seja criada várias classes anotadas com 
@ServerEndpoint, e que todas compartilhem do mesmo objeto do tipo 





ConnectedUsers. A única preocupação necessária é a de evoluir a classe 
ConnectedUsers, para que ela suporte clientes vindos de endpoints di- 
ferentes. 

Você já está quase no fim do livro! No próximo capítulo, será comentado 
detalhes importantes que você deve levar em consideração quando for reali- 
zar o deploy da sua aplicação, além de algumas opiniões importantes sobre 
algumas partes que poderiam ser melhores dentro da especificação. 

Minha dica é que você já finalize o livro, não deixe para amanhã o que 
você pode fazer agora. 
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Ultimas considerações técnicas 


16.1 DEPLOY 


Uma parte muito importante na vida de qualquer aplicação é a sua instalação 
no ambiente de produção, momento também conhecido como deploy. Para 
que o deploy seja o mais fácil possível, idealmente todas as configurações de- 
veriam ficar dentro da própria aplicação, como fizemos no momento da con- 
figuração do tópico do JMS. Entretanto, as nossas configurações de acesso a 
banco de dados e envio de e-mail e segurança ainda ficaram no arquivo do 
proprio WildFly. 

Dado esse cenário, não vamos ter muita escapatória. Será preciso pegar 
uma máquina limpa e instalar tudo o que for necessário para a nossa aplicação 
rodar. 
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Opções de servidores 


Estamos vivendo a época dos clouds. Criar e destruir máquinas são ope- 
rações que estão a um clique de um botão em uma interface web. Vamos tirar 
proveito disso e conhecer três boas opções do mercado. 

Vamos começar pela Amazon e pela DigitalOcean. Ambas oferecem 
toda a infraestrutura necessária para você criar seus servidores e instalar tudo 
o que for necessário para que sua aplicação execute. 

Como a responsabilidade de instalar e cuidar dos softwares necessários 
para a execução do sistema é do programador, esse tipo de cloud é conhecido 
como IAAS, acrônimo para Infrastructure as a Service. Este autor gosta muito 
da DigitalOcean, por conta da maior simplicidade. 

Uma terceira opção, especificamente para o mundo Java EE, é o 
OpenShift. Além de fornecer a infraestrutura, eles também possuem painéis 
de configuração em que é possível adicionar servidores de aplicação, bancos 
de dados e mais uma outra grande variedade de softwares. 

Nesse tipo de cloud, o desenvolvedor fica responsável apenas por enviar 
o código, todo o resto deveria ser de responsabilidade do serviço de cloud. 
O problema, como já comentamos, é que temos algumas configurações que 
ficam nos arquivos de configurações. Por exemplo, o OpenShift até resolve a 
configuração do banco de dados, mas ainda nos deixa a ver navios em relação 
ao e-mail e a parte de segurança. 

Por conta desses problemas, este autor prefere ainda não usar o OpenShift 
como opção de servidor. De qualquer forma, esse de tipo de cloud, que oferece 
além da automatização da infraestrutura de máquinas, também a automati- 
zação da infraestrutura de software, é conhecido como PAAS, acrônimo para 
Platform as a Service. Outra opção nessa linha é o CloudBees. 

Lembre-se de que realizar o deploy não muda muito em relação ao que 
você já vem fazendo localmente. Você precisará ter um banco de dados, um 
WildFly instalado na máquina de deploy e o war da sua aplicação, para que 
você possa adicionar na pasta stadalone/deployments do próprio Wild- 
fly. Lembre-se apenas de criar o DataSource de produção com o mesmo 
nome que você criou o de desenvolvimento. 
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Dependências necessárias 


Para gerar o arquivo war de deploy usando o Maven, é necessário que ro- 
demos o comando caminhoParaMaven/bin/mvn package. O problema 
é que, quando executamos essa linha, recebemos os seguintes erros no con- 


sole: 


[ERROR] COMPILATION ERROA 








nto) jbass-developar-eoals/cosadscodiga/src/main/javalbr/com/cosnascodiga/nade Ls /Gystemlises. java: [17,43] package or 





rrcomicasadocodiga/sade ls /Systemisar. jave: (10,49) package or 







os 4-deve Loper-too 







deve loper-tools/casmdocodigo/sr package 


se-developer-tnals/casadocodiga/sre/eain/javarbr/cos/casadocod iy var 113,30) package 





Fig. 16.1: Problema de compilação 


Aconteceram muito mais erros do que o exibido, mas esse trecho já nos 
passa uma ideia. O Maven não está conseguindo encontrar as dependências 
necessárias para compilar nosso código. 

Como adicionamos o WildFly no nosso projeto, dentro do Eclipse, esse 
problema ficou mascarado. Só que quando vamos compilar direto pelo ter- 
minal, é necessário ter todos os jars necessários para que tudo funcione. 
Para resolver essa questão, basta que as dependências necessárias sejam adi- 
cionadas no pom. xml. 


<!-- javaee7 api --> 


<dependency> 
<groupId>javax</groupId> 
<artifactId>javaee-api</artifactId> 
<version>7 .0</version> 
<scope>provided</scope> 
</dependency> 


<dependency> 


<groupId>org. picketbox</groupId> 
<artifactId>picketbox</artifactId> 
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<version>4.9.2.Final</version> 
<scope>provided</scope> 
</dependency> 


<dependency> 
<groupId>org. hibernate</groupId> 
<artifactId>hibernate-validator</artifactId> 
<version>5.2.0.Final</version> 
<scope>provided</scope> 

</dependency> 


<dependency> 
<groupId>org. jboss. resteasy</groupId> 
<artifactId>resteasy-jaxb-provider</artifactId> 
<version>3.0.11.Final</version> 
<scope>provided</scope> 

</dependency> 


<dependency> 
<groupId>org.hibernate</groupId> 
<artifactId>hibernate-core</artifactId> 
<version>4.3.10.Final</version> 
<scope>provided</scope> 

</dependency> 


<dependency> 
<groupId>org.hibernate</groupId> 
<artifactId>hibernate-entitymanager</artifactId> 
<version>4.3.10.Final</version> 
<scope>provided</scope> 

</dependency> 


Perceba que deixamos o escopo de todas essas novas dependências como 
provided, justamente para explicar ao Maven que elas são úteis na compi- 
lação, mas que não devem ser empacotadas no war final. 
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16.2 PROFILES 


Não é anormal termos informações que variam entre os ambientes que execu- 
tamos o nosso código: configurações de banco de dados, classes que precisam 
ser carregadas etc. O mundo Java EE ainda carece de uma especificação que 
adicione a parte de environment à nossa aplicação. 

Os alternatives do CDI ainda são configurados via XML, o que nos deixa 
com pouca flexibilidade para indicar qual o ambiente que está sendo execu- 
tado no momento. Até existe uma iniciativa da Apache com o projeto Tamaya 
(http://tamaya.incubator.apache.org/) , mas ainda estamos longe de ter todas 
as especificações ligadas a uma especificação de ambiente, como elas já estão 
ligadas ao CDI. 


16.3 TESTES 


Outro ponto que ainda deixa a desejar dentro da especificação Java EE é o 
apoio para o ciclo de testes da nossa aplicação. Talvez, não seja nem respon- 
sabilidade da especificação, mas como todos os componentes do nosso código 
são, de alguma forma, ligados ao Java EE, era mais do que justo que tivéssemos 
alguma ajuda nessa área. 

Precisamos iniciar contextos do CDI, criar e destruir bases de dados, tes- 
tar invocação de métodos nos beans do JSF ou recursos do JAX- RS, enfim, 
uma área que ainda pode ser bem explorada. 


16.4 PROJETOS PARALELOS QUE PODEM NOS AJUDAR 


Na tentativa de fechar alguns dos buracos que citamos neste capítulo, alguns 
projetos foram criados pela comunidade: 


e DeltaSpike: um conjunto de bibliotecas que podem ajudar em várias 
partes do projeto. Por exemplo, eles têm uma implementação de profi- 
les. 


e Arquillian: a ideia é facilitar os testes integrados com o container. Por 
mais que tenha seu valor, ainda é muito complexo e, na opinião deste 
autor, mais atrapalha do que ajuda. 
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Esses dois projetos já estão bem famosos. O DeltaSpike realmente pode 
ter seu valor, já que ele se aventura em áreas que ainda não estão tão fortes na 
especificação. Como comentado, ele traz uma implementação para a parte de 
profiles, assim como tenta ajudar, por exemplo, na parte de testes. 


16.5 CONCLUSÃO 


É sempre importante ter um olhar crítico sobre todas as soluções que usamos. 
O conjunto de tecnologias providas pelo Java EE ainda carece de melhorias 
em alguns pontos. Mesmo assim, a versão 7 da especificação trouxe muitas 
facilidades, como vimos no decorrer do livro. Vale muito a pena utilizá-la, 
desde projetos simples até complexos, já que as APIs estão muito fáceis de 
serem aproveitadas. 

Este foi o último capítulo técnico do livro! No próximo, aproveito para 
agradecer a você pela companhia e também deixo meus contatos, para que 
não percamos a amizade! 
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Hora de praticar 


Muito obrigado por ter ficado comigo durante toda a jornada do livro! É 
muito importante que você tente praticar tudo o que foi estudado. 

Hoje em dia, no mundo Java, as duas melhores plataformas de desenvol- 
vimento são o Java EE e o Spring. Seja pragmático, tente conhecer bem dos 
dois mundos e tenha as informações necessárias para tomar a melhor decisão 
no seu projeto. 

Apenas para dar um panorama, a disputa está muito acirrada. Enquanto 
o Spring tem componentes mais bem conectados e traz coisas como Profile 
e facilidades para testes; o Java EE 7 fornece APIs para trabalhos complexos, 
mas que são expostas de maneira muito simples para o programador. 

Tudo dependerá das necessidades da aplicação e das restrições, que mui- 
tas vezes são impostas pelos clientes. Não seja apaixonado, crie uma tabela de 
decisão e veja quais são os pontos necessários, providos pelos dois lados, que 
podem lhe auxiliar para seguir com o melhor caminho técnico. 
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Para concluir, é muito importante que você continue estudando! Faça 
mais projetos, leia as especificações, ajude as pessoas nos fóruns e tudo mais. 
Toda fonte de aprendizado vai ser importante no momento em que a situação 
complicada chegar. 


17.1 ESTUDAMOS MUITOS ASSUNTOS! 


Conseguimos um feito quase raro, usamos diversas especificações sem forçar 
a barra em nenhum lugar. Tudo que foi utilizado teve um motivo e poderia 
ser aplicado caso você estivesse construindo qualquer outra aplicação. 

Por sinal, apenas reforçando, este autor recomenda fortemente que você 
refaça a aplicação inteira, ou que pegue uma outra aplicação de que você gosta 
e tente construir uma similar. 

Que tal tentar implementar várias funcionalidades do facebook? Aque- 
las atualizações dos comentários dos posts parecem ser um ótimo caso para 
a utilização de WebSockets. Existem várias aplicações que podem servir de 
inspiração! 


17.2 MANTENHA CONTATO 


Estou completamente disponível para ajudá-lo onde for possível. Você pode 
me achar das seguintes formas: 


e Por e-mail, basta enviar uma mensagem para livrojavace gmail.com; 
e Caso use o Twitter, é só acessar https://twitter.com/alberto souza; 


e Ainda há a possibilidade de acompanhar meus projetos pelo GitHub, 
basta acessar https://github.com/asouza. 


e Caso queira postar uma dúvida e ainda ajudar outras pessoas, use o 
fórum criado especialmente para o livro, disponível em https://groups. 
google.com/forum/#!forum/livro-javaee. 


Por último, todo e qualquer feedback sobre o livro é bem-vindo. Use o 
fórum ou mande diretamente para meu e-mail. Escrevê-lo foi um grande 
desafio, espero que ele tenha sido de alguma valia para você. 
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